I’m trying to understand how Timers behave.
Let’s imagine I reset a Timer ModeMyltiple with a period = 2000 (2 sec)
If I assume that now is time 0 and the computer is idle, the Timer will fire at time 0, 2, 4, 6, 8, 10, 12, etc
Let’s suppose that the code in Action takes 2.5 seconds to finish.
Which is the correct sequence of times to fire the timer:
A; 0, 2.5, 5, 7.5, 10…
B: 0, 4, 8, 12…
C: Nothing of this
In a situation I ran into when porting from OS X to Windows (the task runs in 10s of ms in OS X, but takes secs in Windows), you’ll have overlapping execution instances - your option C.
In that case, I’d weigh the purpose of firing a timer more frequently than the task can be run and simply adjust the timer period or create a Do … Loop in a Thread to continually execute the task in (pseudo)parallel to the main loop.
For my problem, we’re trying to determine why each iteration of the task takes so bloody long on Windows.
for some reason the timer period granularity on windows is not as granular as mac (or I guess linux). it has something to do how windows does timers. I am dragging this info from the way back of my skull. so it might be a little off.
The first firing of the timer will be at 2, not at 0
Some programmers set the initial period to something like 100, then after the initial firing they change the period to 2000, so they can get an immediate fire then the desired period.
Proof is in the pudding. I made a small project with a 2000 timer, in which I inserted an operation that takes 2.5 seconds to complete. Here is the debuglog, where "- "means the start of action and 2.5 the end of the operation. The debug log shows each time Action takes place.
So it appears that this test identifies the firing and skipping an interval because it is still running form the previous interval and the actual period becomes 4 seconds. This would match both Ramon’s B option and Roger’s comment about it not firing at the 0’th moment.
My Windows experience must have been tainted because of the underlying latency of the Shell class in that test.
I can’t help but chuckle when people misquote cliches … it’s actually, “The proof is in the tasting of the pudding.”
I did the experiment on Mac, and now I have erased the project. But chances are the behavior of Xojo will be the same.
Maybe the proper way to use a timer with a long operation is to use a single mode and restart the timer right at the end of complete, so the interval remains constant.
According to several sources, the idiom is “The proof of the pudding is in the eating” and is said by Wikipedia to date back to the 17th century. That said, sorry for the conventional saying, but I referred to the Hercule Poirot’s episode where someone hides a stolen ruby in the Christmas pudding, placing the proof effectively in the cake. I promise to find another image next time.
I was just poking a bit of fun at you :). We’re big Poirot fans in my house (except for the Peter Ustinov movies - he was too affected). The phrase I quote was one of the two originals - the second being the “The proof of the pudding is in the tasting”. Agatha Christie’s modification was to play on the visual concept of the jewel being found in the Christmas Pudding.
One Doctoral thesis even put forth that the original term was based upon “putting forth evidence” as making a statement true. Something on the order of “The proof sir, of your claim that my wife had carnal relations with your goat is in the putting forth of evidence that supports your ridiculous accusation”.
I guess there are many “discussions” on the root and right of the phrase.
Regardless, the cliche was quite appropriate.
Back to the topic of the Timer firing, as I said, I suspect that part of my Windows issue was related to the other, deeper seated shell issue. The shell was running the external task in a thread and the timer was trying to get the results and update the UI elements. This resulted in the UI being updated in an overlapping manner on the normal schedule of 500ms (which was more than enough time under OS X) rather than skipping iterations as your “pudding” proved :S.
Thanks for all your comments.
As I’m using Windows I’ve searched in the MSDN and found this page: Waitable Timer Objects
It seems that Xojo Timers are native OS Timers, so their behaviour (what I wanted to know) depends a lot on the OS.
Experimenting, as Michel did, is the only way to try to understand something about it.
That is where restarting a single mode timer at the end of Action will probably be better, because it takes into account the time it takes for the shell to complete. The experiment clearly shows that the multiple timer does not fire at the planned time.
It is a terrible difference and it can make shell completely unusable.
On Mac, Spotlight indexing is capable of stealing quite a bit of processor time and slowing down everything. I have turned it off on my old MacBook and the speed improvement is striking. Seems like the same can be true on Windows with automatic search for network folders and printers.
The issue here is what to do from inside an app to speed up shell things, and apparently there is nothing
Actually, the team are working on it based on a feedback report update. In this particular instance, it’s the polling latency of the Windows shell implementation rather than Explorer’s many tendrils getting involved. If I manually run the task in a cmd.exe shell, it’s as fast as on OS X.
Therefore, it turns out that my instance with overlapping timer firing was not specific to the timer, but rather to the unexpected sluggishness and latency in the Shell that the timer was monitoring. The timer was doing what it should and it’s run time was less than 2MS.
[quote=104635:@Tim Jones]Actually, the team are working on it based on a feedback report update. In this particular instance, it’s the polling latency of the Windows shell implementation rather than Explorer’s many tendrils getting involved. If I manually run the task in a cmd.exe shell, it’s as fast as on OS X.
Therefore, it turns out that my instance with overlapping timer firing was not specific to the timer, but rather to the unexpected sluggishness and latency in the Shell that the timer was monitoring. The timer was doing what it should and it’s run time was less than 2MS.[/quote]
Then it is the Xojo shell which is sluggish ? Could you not use mode 1 to somewhat free up the timer ?
Unfortunately, no. The two processes must talk to one another throughout the run. My simple tests run in the low minutes (at least, on OS X and Linux), but the process could, in fact, run for days before completing (when we’re moving data at 504GB/hour, dealing with 55TB of data can take over 5 days to complete).