Assignee: nobody → general
Product: Firefox → Core
Version: 13 Branch → Trunk
This is exciting. 35% of the time is under js::CrossCompartmentWrapper::set (and 43% total is under the corresponding SetElem stub calls). 20% of the time is under js::CrossCompartmentWrapper::get (and 28% total is under the corresponding GetElem stub calls). Luke, Bobby, does Firefox 13 have cpg? Or is what I'm seeing even slower than Firefox 13? Reporter, does the testcase involve script running in one window touching objects in another window or frame? Based on the profile it certainly looks like it does...
Oh, and to be clear... of that 35% under CrossCompartmentWrapper::set, about 2% is actually doing sets on a typed array. The rest is proxy overhead, JSComparment::wrap, js::ContextStack::pushDummyFrame. pushDummyFrame via that callpath is 10% of the profile I'm looking at!
Ah, yes. No cpg in Firefox 13. This is ridiculously, ludicrously slower on trunk than in Fx13. :( I filed bug 774119 on the trunk behavior. There's no point even measuring/profiling here until that's fixed. :(
Depends on: 774119
Ah so I guess this was the very hot access, I saw with the inspector.
We should definitely rip out dummy frames: bug 625199.
On the question of one window touching another window/frame. If it is doing what you suggest, it isn't by design. The emulator is a port of jDosbox to Js with the help of Google web toolkit (GWT). More info on sourceforge.net/projects/jsdosbox/ (jsdosbox.apppsot.com). I guess i'm coding a level removed. The emulator is however more advanced then my previous effort sourceforge.net/projects/jspcemulator/ (pc-emulator.appspot,com) from way back. Curiously the port of JPC ran in FF somewhat closer to the speed of Chrome then what is seen here. That said they work very differently and much of the tech I added wasn't available back then.
You need to log in before you can comment on or make changes to this bug.