From Naveed's Browsermark "DOM Search" test results (bigger is better): * Chrome 31 = 8,144 * Chrome 27 = 7,848 * Firefox 25 = 5,195 * Firefox 22 = 5,260 * IE11 = 10,461 Firefox 25 is slightly slower than Firefox 22.

On trunk, we're close to parity, I think. Fixing bug 820848 would help even more, maybe. One interesting feature here is that we end up with 11% of our time under jit::DoGetPropFallback. In the end it ens up doing a get on the HTMLDocument, but via all the proxy machinery, not the IC. I'll look into what property exactly and why. Another 8% is js::GetProperty, again falling into the proxy machinery, again not via the IC. 15% of the time is under regexp_exec. The vast majority of this is CreateRegExpMatchResult and the DefineGeneric calls it does. In fact, smells a lot like bug 879402. And bug 876846 (which is not surprising; the latter has code similar to this benchmark). 25% of the time is under array_slice. 1/4 of this is SetArrayElement, and about half is going through the proxy getElementIfPresent machinery on an HTMLCollection. That's bug 697343. Again, mostly seems like a JS testcase...

> jit::DoGetPropFallback I expect this is the same issue as we found in bug 922071. > Another 8% is js::GetProperty Also as discussed in bug 922071.

So for me, in a build with bug 879402 fixed, I see numbers kinda like: Firefox nightly: 9240 Chrome dev: 6516 For comparison, fx26: 4026 Nightly without bug 879402: 8208 A profile of the nightly with bug 879402 fixed shows: * 18% of the time under array_slice, of which 12% is in the HTMLCollectionBinding code. * 10% under array_push * 10% under js::GetProperty * 9% under regexp_exec, breaking down as 6% CreateRegExpMatchResult (half of this is malloc under createArray!) and 3% ExecuteRegExp. * 5% jit::DoGetPropFallback. * 4% js::SetObjectElement * 2% calling getElementById * 2% calling getElementsByTagName * 3% CloneRegExpObject * 3% CreateThisForFunctionWithProto and some long-tail stuff (e.g. js_Date is popping up at 1% now).