[webkit-dev] Potential performance/responsiveness problem with timers

[David Hyatt]

My understanding of the Mozilla system is that it has real trouble  
firing timers at the correct times because of the additional  
processing delays you described.

I think our current model is sound (given that we have to process  
these timers on the main thread anyway, so they all wait on one  
another regardless), with the caveat that we should always be on the  
lookout for any timers that can take a long time, since we'll want to  
add code to force those kinds of callbacks to break up their work (we  
do this already when parsing for example, and we also warn about slow  
JS).

It's also worth noting that the OS X timer is very accurate, but the  
current Windows code is just using SetTimer, and so is very  
inaccurate.  Any testing should be done on OS X only, since the Win32  
timer code imposes additional processing delays because it lacks high  
resolution timing.  In my experiments, some DHTML movement test cases  
can be as much as 1.5-2x slower on Win32 than OS X because of this  
issue.

dave

On Jan 11, 2007, at 7:10 PM, Don Gibson wrote:

> I've been looking at the code in Timer.cpp lately, and I have a  
> vague worry that there might be problems, but no real concrete  
> testcases of something actually being wrong.
>
> When firing timers, we set a single system timer for the soonest  
> timer.  When it goes off, TimerBase::fireTimers() sequentially  
> pulls off all the timers in the ready queue and fires them.  This  
> firing is done via callback directly to the fire handlers, which  
> can take arbitrary time to execute.  More worryingly, we process  
> all timers before returning to the global message loop.  I'm  
> concerned that setting a large number of timers, or having handlers  
> that take a while to execute, could cause poor performance/ 
> responsiveness due to starving the global message loop.
>
> The Mozilla timer system gets around this problem by posting  
> individual messages to the main message queue for each timer that  
> needs to fire instead of directly calling back to handlers from the  
> timer-processing loop.  However, this means the actual firing of  
> each timer is additionally delayed by other processing other items  
> in the message queue.  Also, a careless design for this could queue  
> up multiple "timer fired" messages for a timer that was behind on  
> processing them.  (Imagine an autoscroll timer set to repeat every  
> 100 ms, and a page that took a long time to do individual paints.   
> Multiple scroll messages might queue up by the time the user's  
> mouse input messages could be processed to cancel the scroll,  
> leading to scrolling continuing for a while after the user had  
> cancelled.)
>
> Still, even with these concerns, I wonder if the Mozilla system  
> might not be better.  Any thoughts on particular cases that would  
> perform poorly in either system, or whether this change would be  
> beneficial?
>
> Don
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev