Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Trying to use the timer functions to measure performance issues, I found that timers called multiple times (e.g., timer_start('saveIDMapping'); timer_stop('saveIDMapping'); timer_start('saveIDMapping'); timer_stop('saveIDMapping);) reported ridulously high values. The problem is that timer_read() returns the full accumulated time across all calls, and timer_stop() adds the timer_read() value to the already-accumulated value - thus, after the first read $timers[$name]['time'] gets double-counted each time (can you say "exponential"? good...).
Patch forthcoming...
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | timer_stop.patch | 972 bytes | mikeryan |
Comments
Comment #1
mikeryanNote related issue #84008: timer_read() returns NULL (no value) after timer_stop() - this fix should be added to the D6 patch there.
Comment #2
moshe weitzman CreditAttribution: moshe weitzman commentedfix looks proper to me.
Comment #3
webchickIs there a way to add a test for this, by chance?
Comment #4
moshe weitzman CreditAttribution: moshe weitzman commentedWe could add a test which calls timers 3 times and sleeps for a couple seconds between each but thats gonna slow down the whole suite and i don't really see that much benefit. If you do timings for something other than sleep() then you have little clue about how accurate your timer is.
Considering that nothing breaks if timers break, and considering that this API has hardly changed in 8 years, I think we can proceed with this bug fix without a test. Please.
Comment #5
Dries CreditAttribution: Dries commentedI'm comfortable with this patch without test so I committed it to CVS HEAD.