Track performance on the quirksmode dom/innerHTML perf test




10 years ago
2 days ago


(Reporter: bz, Unassigned)


({meta, perf})

meta, perf
Dependency tree / graph
Bug Flags:
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)




(2 attachments)

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.
jst suggested that we could get rid of some QIs in CreateElement, possibly.
Created attachment 324121 [details]

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.


10 years ago
Flags: wanted1.9.1+
Worth reprofiling with current trunk given all the DOM perf improvements that have landed in the last 13 months?
Keywords: meta
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.
Depends on: 502937, 77956
Filed bug 503028 on the cell list thing.
Depends on: 503028

Comment 7

2 days ago
Per policy at If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.