437733 - [meta] Track performance on the quirksmode dom/innerHTML perf test

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Boris Zbarsky [:bzbarsky]]

In brief, we're slower than we'd like to be on the tests on that page (which I will attach momentarily).

Profiling the very first test on a current 1.9.0 Mac nightly:

   33% of the time is spent under XPCConvert::NativeData2JS
     (JS-wrapping all those nodes, etc).
   6% is the security manager (CanAccess call from XPCWrappedNative::CallMethod)
   2.5% is XPCCallContext::CanCallNow
   2% is XPCConvert::JSData2Native
   2% XPCCallContext constructor

I should note that total time under XPC_WN_CallMethod is 87%.  The remaining 33%
or so (yes, the numbers don't quite add up; there's a long tail) are actually
under NS_InvokeByIndex_P (that is, in DOM/layout code).

   5.5% CreateElement
   2.7% CreateTextNode
   3.7% inserting kids of a table cell (about a third growing the child array)
   17.4% frame construction under the final insert into the div

Frame construction is about half style resolution (probing pseudo contexts,
actual style resolution, etc) and about half scattered about the frame
constructor in various tiny ways (1% here, 0.8% there).  Less frame constructor
code would likely help.  ;)

The second test is nearly identical.

The third test we spend all of 44% of the time in dom/layout code; looks like
most of the difference is the actual child list munging.  Odd.

I didn't look at the innerHTML tests for now; we have some existing data on that
stuff tracked by other bugs.

So the #1 thing we could do here would be to reduce the time spent getting from
JS into C++ and back from 50%-ish of the total time to something less.

That's the only obvious big win outside the JS engine itself (which is only 13%
of this testcase anyway).  Everything else would take work in all sorts of
places to squeeze just a bit more out.

We might want to look at the actual child insertion in nsGenericElement, I
guess.  Not sure how we can best improve it. 

Please file bugs as needed blocking this one on particular perf improvements.

Comment 1

[Boris Zbarsky [:bzbarsky]]

jst suggested that we could get rid of some QIs in CreateElement, possibly.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: CSS for test

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

This is all set up to run shark as the profiler for each test, if shark is set up to do remote sampling and the build has the shark stuff enabled.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Worth reprofiling with current trunk given all the DOM perf improvements that have landed in the last 13 months?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, maybe.  With a 2009-07-07 nightly (so should have slimwrapper):

First test:  
60% of the time is frame construction.  Webkit cheats by doing it lazily;
    that's bug 502937.  A lot of this (something like 1/4) is pseudo probing;
    do we have an existing bug on that?
6% the actual CreateElement call.
3% CreateTextnode
9% xpc_qsXPCOMObjecToJsval
5% some XPCCallContext and QI stuff
6% appendChild calls outside the document
2% jit stuff (testcase doesn't quite jit)

Second test:
65% frame construction.  
9% CloneNodeImpl
4% JS_ComputeThis
10% xpc_qsXPCOMObjecToJsval for the clone (all of it slimwrapper construction)

Frame construction certainly hasn't gotten slower, so it going from 17% to 60% is a good sign.  ;)  Once we make that lazy, though, the overhead will go back to being about 50% of the time.

Third test:
55% frame construction.
8% rebuilding the cell list for insertCell; this should be fixable.
5% xpc_qsXPCOMObjecToJsval for the cell insert.
7% actual insertBefore
The createTextNode and appendChild stuff looks like like in the first two profiles.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Filed bug 503028 on the cell list thing.

Comment 7

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.