606503 - Improve perfomance in hixie's Dom Core Perfomance test

Status: RESOLVED WONTFIX

(Mozilla Labs :: Operator, defect)

Description

[Alex Shilov]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101021 Firefox/4.0b8pre
Build Identifier: 

The addon slowed down dom perfomance on pages
http://www.hixie.ch/tests/adhoc/perf/dom/artificial/core/001.html and
http://www.hixie.ch/tests/adhoc/perf/dom/artificial/core/002.html
see Bug 606474

Reproducible: Always

Comment 1

[Mike Kaply [:mkaply]]

The problem is that I'm listening for DOMNodeInserted and DOMNodeRemoved messages.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Well, and doing some processing for each one, right?

Comment 3

[Mike Kaply [:mkaply]]

Way too much processing. Searching the entire doc each time for microformats usinig getElementsByAttribute.

 I remember some talk at one point about a new message for AJAX events to send that says "I'm done" - was that ever implemented? There's really no good way to do what I'm short of checking the document every few seconds.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Could you just have your mutation listeners set a timer (if not already set) to check the doc in a few seconds?  That wouldn't require you to always poll, but would allow you to coalesce changes that happen together.  That's basically what we do for dom/style changes in gecko itself....

Comment 5

[Mike Kaply [:mkaply]]

(I haven't looked at this code in a while).

Looking closer, I do batch changes. No idea why that's not happening here. Researching...

Comment 6

[Mike Kaply [:mkaply]]

Even if I do nothing on the DOMInsert/Remove (call a function, immediately return), It still hangs the browser.

Total elapsed time: 24809ms (average per iteration: 248.09). Ideal time: 0ms.

So even coalescing won't fix this.

With just DOMNodeInserted

Total elapsed time: 10490ms (average per iteration: 104.9). Ideal time: 0ms.

with just DOMNodeRemoved (same as with nothing)

Total elapsed time: 957ms (average per iteration: 9.57). Ideal time: 0ms.

The very act of listening to DOMNodeInserted in this case creates the main bottleneck.

Comment 7

[Mike Kaply [:mkaply]]

That was on FF 3.6, BTW.

Just tested on latest trunk build and it's worse than 3.6.

Total elapsed time: 15906ms (average per iteration: 159.06). Ideal time: 0ms.

Increase seems too large to me to be timing.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Interesting.  What object do you set your event listeners on?  And capturing or bubbling?

Comment 9

[Mike Kaply [:mkaply]]

I set them on the entire document (ownerDocument for the event.target on pageshow)

useCapture is false.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Version of 001.html with an inserted mutation listener

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Same for 002.html

Comment 12

[Boris Zbarsky [:bzbarsky]]

I profiled the modified 002.html.  91% of the time is under FireNodeInserted.  This breaks down as:

  3% HasMutationListeners (doing QI, etc)
  4% self time in nsEventDispatcher::Dispatch
  4% nsXULElement::PreHandleEvent getting insertion parents, etc.
  3% nsCOMPtr stuff in Dispatch
  2% DuplicatePrivateData.
  1% more QI in Dispatch.
  1% Release on elements in Dispatch.
  6% self time in HandleEventTargetChain
  2% GetListenerManager and refcounting of elements and windows in
     HandleEventTargetChain
  8% under nsCxPusher::RePush under HandleEventInternal
  2% creating DOM mutation event objects
 40% xpconnect-stuff under the actual call to HandleEvent on the XPCWrappedJS.

I hate mutation events.  :(

Comment 13

[Salar]

The test shows that the DOM operations are way too slow in android platform.

Tested on HTC Desire C with Cpu Snapdragon 600MH

Firefox 26.0: 7242ms
GoogleChrome: 31: 827ms

Comment 14

[Boris Zbarsky [:bzbarsky]]

Salar, could you please file a separate bug on the issue you see and cc me?  This bug is about performance when a particular addon is installed.

Comment 15

[Mike Kaply [:mkaply]]

Operator isn't maintained anymore (certainly not by Mozilla Labs).