[webkit-dev] Potential performance/responsiveness problem
mjs at apple.com
Fri Jan 12 01:28:33 PST 2007
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
> 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
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.
More information about the webkit-dev