230610 - Posting reflow events takes a lot of time (nsIEventQueue)

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Boris Zbarsky [:bzbarsky]]

From a profile (setting nodeValue on a textnode over and over again):

 41207   7      995 PresShell::ContentChanged
                648 nsCSSFrameConstructor::ContentChanged
                316 PresShell::DidCauseReflow

Of the 316 hits under DidCauseReflow, 304 are in POstReflowEvent(), almost all
of them (290) in GetSpecialEventQueue.  Partly this is due to event queues not
being too quick to get things like the youngest queue, partly due to things like
having to enter and exit monitors.

In any case, is there any way we can avoid having to call GetSpecialEventQueue
quite so much here?  I guess the problem is that even if we have an event
posted, we may want to post another one if someone is doing something sync that
pushed a new queue, right?  Is that the problem we are trying to solve?  Maybe
that would be better solved by a fast "IsQueueYoungest()" method on
nsIEventQueue or some such?

Comment 1

[Tim]

see attachment 138789 [details] from bug 230609 for the profiled code.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that we have code like this for paint events too.  See
nsViewManager::PostInvalidateEvent.   It doesn't come up as much in profiles,
because it's only used for view update batches, which don't happen quite as
often.  But in DHTML that changes properties that need a repaint, I fully expect
that code to be hit a lot.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 326273.