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

[Don Gibson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070111/e2afbd4c/attachment.html