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] 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.
Worth reprofiling with current trunk given all the DOM perf improvements that have landed in the last 13 months?
9 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.