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

[Maciej Stachowiak]

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.

I see your point about the theoretical problem, but we haven't seen  
an actual problem in practice. WebCore itself does not send that many  
timers, and JS timers have a minimum delay interval, so it's hard for  
them to starve the event loop. I guess an interesting test case would  
be to make a web page that sets a huge number of JS tiers that go as  
fast as possible and do lots of work, and see if it hurts  
responsiveness. I'm not sure how likely a scenario this is, except  
possibly as an attempted denial of service attack.

> 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?

The Mozilla system would probably make everything relying on a timer  
marginally slower. If starving the event loop turns out to be a  
problem, I think it would be more sensible to set a maximum time  
interval for which timer handlers will be processed (after which  
another zero-delay timer is set) than to force each timer handler  
onto its own run loop thread.

But anyway, like I said, we haven't seen any real-world  
responsiveness problems due to this setup, and failing that I am not  
inclined to worry about it.

Regards,
Maciej