Problem/Motivation
timer_read() currently does not work after timer_stop().
Proposed resolution
Use $timers[$name]['time'] inside time_read() and timer_stop() instead of solely relying on $timers[$name]['start'];
Remaining tasks
Backport to d6
User interface changes
none
API changes
none
Original report by @plumbley
timer_read() currently does not work after timer_stop().
This has potential for confusion if by design, so perhaps the documentation should warn against it. E.g. instead of "Read the current timer value without stopping the timer." it could add "Important: the timer MUST be running when timer_read. is called".
To replicate, try e.g.
timer_start('test1');
echo timer_read('test1') . '<br />';
timer_stop('test1');
echo timer_read('test1');
which seems a reasonable thing to do, but you get e.g.
------
0.04
Notice: Undefined index: start in c:\program files\apache group\apache\htdocs\drupal\includes\bootstrap.inc on line 58
1158186408044.1
------
It looks like this is also true for CVS as well as 4.7.3. Mark.
Comment | File | Size | Author |
---|---|---|---|
#28 | timer-stop-84008-28.patch | 812 bytes | jacob.embree |
#23 | timer_stop_D6.patch | 1002 bytes | mikeryan |
#11 | 84008_accumulate_timer_value.patch | 2.46 KB | deviantintegral |
#9 | issue-1063313.patch | 698 bytes | lambic |
#6 | issue-1063313.patch | 749 bytes | lilou |
Comments
Comment #1
plumbley CreditAttribution: plumbley commentedActually this is due to $timers[$name]['start'] being unset by timer_stop(), breaking the logic of the following line lin timer_read():
So its actually easy to change this to make it work whether the timer is running or not - simply set $diff here to 0 if $timers[$name]['start'] is not set, i.e.
Patch attached fixes this for CVS of 14 Sept 2006 (Similar applies to 4.7.3, but I realized it may be a bit pointless for 4.7.3 now with something so minor). Mark.
Comment #2
drummpatching file includes/bootstrap.inc
Hunk #1 FAILED at 59.
1 out of 1 hunk FAILED -- saving rejects to file includes/bootstrap.inc.rej
Comment #3
plumbley CreditAttribution: plumbley commentedPatch no longer applies, since a version was fixed by chx a couple of months later (version 1.129, Sun Nov 12 00:21:15 2006 UTC).
However, the new implementation of timer_read() does not return a value (i.e. implicitly returns NULL) after timer_stop() instead. This seems strange logic to me - why not allow the timers to be read after timer_stop()?
I have marked it as a "feature request" now instead with updated title (since it would be added functionality), but please mark as closed if this is the intended behaviour.
Best wishes, Mark.
Comment #4
PasqualleComment #5
lilou CreditAttribution: lilou commentedComment #6
lilou CreditAttribution: lilou commentedoups ...
Comment #8
EvanDonovan CreditAttribution: EvanDonovan commentedThis is a very confusing situation (that timer_read() doesn't work if timer_stop() has been called). Could someone please re-roll the patch?
Also, could the documentation be updated for 6.x, or, even better, could the fix be backported after it's been applied to 7.x?
Comment #9
lambic CreditAttribution: lambic commentedpatch looks ok, re-submitting for the bot
Comment #10
deviantintegral CreditAttribution: deviantintegral commentedAs-is, this patch appears to be a no-op; I'm still getting NULL after timer_stop().
Comment #11
deviantintegral CreditAttribution: deviantintegral commentedThe documentation makes it seem as if the total running time for a single timer will cause the total time to be accumulated. DX frustration ensues :). The attached patch changes the timer_* functions as well as adds tests for them. The tests are still "needs work", but I'd like feedback as to if this is appropriate for D7 or if it should go to D8.
Comment #12
moshe weitzman CreditAttribution: moshe weitzman commentedAs long as this is a bug report, it can be committed to D7 before the release or afterwars. There is no freeze for bugs.
Comment #13
Dries CreditAttribution: Dries commentedYep, I'd consider this a bug.
Comment #14
deviantintegral CreditAttribution: deviantintegral commentedGreat. Here is an updated patch which includes function comments, and changes the test to be >= instead of >.
I've chosen 3 seconds for the sleep(), but that was just me choosing a number. Could we reduce it to 1?
Comment #16
deviantintegral CreditAttribution: deviantintegral commentedNot sure why the above didn't apply, but I've updated from CVS and it passes tests fine locally.
Comment #17
Dries CreditAttribution: Dries commentedWe should probably use a smaller value, yes. I'd think 1 second ought to be enough, if not, use 2 seconds.
Comment #18
deviantintegral CreditAttribution: deviantintegral commentedHere's an update with sleep(1) instead.
Comment #19
Dries CreditAttribution: Dries commentedLooks good to me. Committed to CVS HEAD. Thanks!
Comment #20
Dries CreditAttribution: Dries commentedComment #21
deviantintegral CreditAttribution: deviantintegral commentedI think this should be backported to D6 and D5 as a bug fix. The attached patch is identical to Drupal 7, minus the simpletest. It applies cleanly to Drupal 5 and Drupal 6.
Comment #22
moshe weitzman CreditAttribution: moshe weitzman commentedComment #23
mikeryanUpdated patch fixing #723436: Timers accumulate at double-speed.
Comment #24
kenorb CreditAttribution: kenorb commentedsimilar issue.
subscribe.
My case:
It returns:
Workaround is to always start timer before you stop it:
Comment #26
EvanDonovan CreditAttribution: EvanDonovan commentedPatches for versions of Drupal prior to D7 will always fail testing.
Comment #27
thedavidmeister CreditAttribution: thedavidmeister commentedpatch does not apply anymore:
but this should be RTBC with a straight re-roll.
Comment #28
jacob.embree CreditAttribution: jacob.embree commentedReroll
Comment #29
thedavidmeister CreditAttribution: thedavidmeister commented