Open Bug 532810 Opened 10 years ago Updated 9 months ago
sessionstore screwing over our dromaeo performance
I was playing around with the dom-traverse dromaeo tests, and discovered that the "childNodes" testcase runs about 2x faster if it's the only one in the set that runs. If I run the "lastChild" testcase before it, then it runs at the slow speed. I did a bit of profiling+debugging and discovered that at least part of the problem was that in XPCConvert::NativeInterface2JSObject we were constructing XPCCallContexts. We were also generally spending more time wrapping/unwrapping elsewhere. So I stepped through that, and discovered that the |flat| we had in NativeInterface2JSObject from our wrapper cache wasn't a slimwrapper. And then I put a breakpoint in MorphSlimWrapper and saw it getting hit with this C++ stack: #0 MorphSlimWrapper (cx=0x101ac00, obj=0x1a6f99a0) at /Users/bzbarsky/mozilla/tracemonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:3772 #1 0x1180d2ba in XPCWrappedNative::GetAndMorphWrappedNativeOfJSObject (cx=0x101ac00, obj=0x1a6f99a0) at xpcprivate.h:2500 #2 0x1186d5ea in XPC_NW_RewrapIfDeepWrapper (cx=0x101ac00, obj=0x1606eaa0, v=443521440, rval=0xbfffbb90) at /Users/bzbarsky/mozilla/tracemonkey/mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp:451 #3 0x1187b772 in XPCWrapper::RewrapIfDeepWrapper (cx=0x101ac00, obj=0x1606eaa0, v=443521440, rval=0xbfffbb90, isNativeWrapper=1) at XPCWrapper.h:321 #4 0x1187a278 in XPCWrapper::GetOrSetNativeProperty (cx=0x101ac00, obj=0x1606eaa0, wrappedNative=0x1ee3de20, id=351333828, vp=0xbfffbb90, aIsSet=0, isNativeWrapper=1) at /Users/bzbarsky/mozilla/tracemonkey/mozilla/js/src/xpconnect/src/XPCWrapper.cpp:735 The JS callstack is: 0 sss_xph_generate(aNode = [object XPCNativeWrapper [object HTMLDivElement @ 0x1ee3de20 (native @ 0x20bbeb10)]]) ["file:///Users/bzbarsky/mozilla/tracemonkey/obj-firefox/dist/MinefieldDebug.app/Contents/MacOS/components/nsSessionStore.js":2916] 1 sss_xph_generate(aNode = [object XPCNativeWrapper [object HTMLFormElement @ 0x1ee3ee00 (native @ 0x20bbfb70)]]) ["file:///Users/bzbarsky/mozilla/tracemonkey/obj-firefox/dist/MinefieldDebug.app/Contents/MacOS/components/nsSessionStore.js":2936] 2 sss_xph_generate(aNode = [object XPCNativeWrapper [object HTMLInputElement @ 0x1ee3f240 (native @ 0x20bbff80)]]) ["file:///Users/bzbarsky/mozilla/tracemonkey/obj-firefox/dist/MinefieldDebug.app/Contents/MacOS/components/nsSessionStore.js":2936] etc. So the problem is that sessionstore is messing with this iframe in the first place (not quite sure why; should it be to start with?) but worse yet its xpath generation forces native wrappers, which slows down all DOM access thereafter.
Oh, I verified that the slowdown effect goes away if I set browser.sessionstore.privacy_level to 2, so this is in fact the only source of the screwage in this case.
Oddly enough, setting to 2 helps on local file but not over http. Or something. At least the dromaeo.com dromaeo is unaffected by that change.
Oh, right. This is only an issue if I change the test to use item() to get the nodes. If it's using  then it's just all bad and the bottleneck is elsewhere anyway.
Or even more precisely, the sessionstore slowdown is not quite 2x; more like 1.5x, on the slower path. But still there. Is there any sane way we can avoid morphing here? Or speed up the XPCConvert code even for the XPCWrappedNative case? Or something?
Blake and I have talked about making security wrappers deal with slim wrappers. It doesn't look too hard. Reducing morphing was one of my quarterly goals, but other things got in the way.
Depends on: 512500
OS: Mac OS X → All
Hardware: x86 → All
jst, you might be interested in this one.
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.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.