Re: SVG speed?

HelderMagalhaes wrote:
>  1. setInterval will conceptually not take into account the time took
> to run the code in each call (please correct me if I'm wrong!)

In Gecko, you're wrong, in that the timer is reset based on when it 
fired, not when the callback returned.  So if you have a 150ms interval 
and you have code that takes 10ms to run that's called from the interval 
timer, the timer will fire every 150ms (and be reset for 140ms from 
"now" when it gets reset after the code has run).  If you use setTimeout 
and reset it from the end of your code it'll fire at 150ms, and then the 
next time at 310ms (150 + 10 + 150).  If you use setTimeout and reset it 
from the beginning of your code you should get behavior similar to 
setInterval.

> so, if the benchmark code is too long and/or the timing too short, this can
> cause really messed up results...

If the benchmark code takes longer than a single interval to run, then 
the interval timer will skip ahead to the next interval.  So in the 
example above, if you setInterval for 150ms, and your code takes 200ms 
to run, then a timer will fire at time 150, then be reset at time 350 to 
fire at time 450 (next multiple of 150 after 350).

If you use setTimeout, this doesn't happen.  So if you set the timeout 
at the end of your code, then it'll fire at 150ms the first time, be 
reset at 350ms, and fire again at 500ms.  If you set it at the beginning 
of your code it'll fire at 150ms, then be reset at 150ms, and fire again 
at 350ms (right after your code finishes, basically).

That all assumes there are no other timeouts racing with the one in 
question, of course.

Note that the timer accuracy involved is rather low (order of 10ms in 
some cases), so any timeouts smaller than about 20ms are likely to be 
pretty unreliable.

>  2. Running one of the test cases in the referenced bug [2] sometimes
> still shows inaccurate timing. Sample using Firefox 3.0.4:
>     [...]
>     f1: 1404ms-> Greater than 10% error!
>     f2: 1403ms-> Greater than 10% error!
>     f1: 593ms-> Greater than 10% error!
>     f2: 593ms-> Greater than 10% error!
>     [...]

I can in fact reproduce this sometimes (not always).  My best guess 
based on things like disk activity and when this happens in relation to 
pageload is that this happens when GC runs very close to the time the 
timer is supposed to fire and takes a few hundred ms.  Note that we do 
correct as you can see above so that the average time taken is right.

>     Intuitively, this specific result set makes some sense as we would
> expect the average timing to correspond to the desired target trigger
> time. But using this for accurate timing measurements can be naturally
> misleading, reason why setTimeout is advised instead.

See above for how setInterval and setTimeout differ (at least in Gecko). 
  Which one you want depends on what you're doing.  Note that if GC 
fires close to a setTimeout timer's due date that timer will file late 
just like a setInterval timer.  In fact, the only difference between the 
two is that for an interval the previous firing time is taken into 
account when scheduling the next firing time, whereas a timeout is just 
scheduled based on when the setTimeout call happens.  All the rest of 
the code is the same.  Using either one for "accurate timing 
measurements" is asking for trouble.

To expand on that, the current interval and timeout timers are both 
somewhat poor as high-quality timers.  But any solution that preserves 
the single-thread-no-reentrancy web programming model has the same 
property, since it has to race other things that are going on.  The way 
to get high-quality timers is to have a system where you get an 
interrupt signal that preempts whatever else is going on (like signals 
in C, say).  I doubt the web is ready to deal with that sort of thing... 
  There are proposals to have high-resolution timers available, but 
given the above issues I'm not sure how much use they would be.

Your other option is to do Date() based timing.  That will work great in 
Gecko.  It'll work really badly for short time intervals in webkit-based 
browsers, since they update their date in 15ms increments (and don't 
consider that a bug).  I have no idea how well it works in Opera or IE.

-Boris