Open Bug 940813 Opened 8 years ago Updated 2 years ago
Browsermark "DOM Advanced Search" is 1
.6x slower than Chrome
From Naveed's Browsermark "DOM Advanced Search" test results (bigger is better): * Chrome 31 = 13,557 * Chrome 27 = 14,034 * Firefox 25 = 8,275 * Firefox 22 = 3,461 * IE11 = 7,613 The good news is that Firefox 25 is 2.4x faster than Firefox 22, but still 1.6x slower than Chrome 31.
Is there a way I can get access to the source of this test?
(In reply to Boris Zbarsky [:bz] from comment #1) > Is there a way I can get access to the source of this test? Yes. I believe Naveed and sstangl have the test sources. I asked Naveed to where other people can get them.
So Sean got me the benchmarks in question and I took a look at this benchmark and did some profiling. First off, the benchmark is largely doing jQuery access to the DOM, not direct DOM calls. It grabs a few lists of nodes, then does each() on them with some callback functions that check for some criteria and if the criteria match pushes the element into a results array, etc. Which brings me to the profile. * Somewhere about 10% is jitcode. * 13% is under js::SetObjectElement, largely calling into DefinePropertyOrElement via SetPropertyHelper. Lots of malloc() for the growElements() that results. This is being called from jitcode, so probably not the results array pushes in the test itself. * 10% is under js::GetProperty. Eventually this ends up doing a .nodeType on a node or a .documentElement on a document. Why are we ending up with the slow stubcalls here instead of the optimized DOM ICs? * 9% is under js_fun_apply. Most of this is array_push or array_concat. * 5% is the innerHTML getter on elements, being called via the generic JSNative IC, not the fast ion LGetDOMProperty thing. Most of this is string ops serializing the DOM fragment. * 5% is str_replace; almost half is self time in that function and the rest is smeared across RegExpShared::execute, RegExpShared::executeMatchOnly, and StringRegExpGuard::init. * 5% is js::CreateThisForFunctionWithProto: getNewType, NewObjectWithType. Then there's a long tail. I will claim that this is fundamentally not a DOM benchmark, except maybe for that innerHTML getter. ;) The speedups from fx22 are probably from the existing work jandem has done on optimizing jQuery stuff.
Oh, and we should figure out why we have that js::GetProperty stubcall!
(In reply to Boris Zbarsky [:bz] from comment #3) > The speedups from fx22 are probably from the existing work jandem has done > on optimizing jQuery stuff. Do you happen to have numbers for FF 28? Comment 0 has numbers for 25 but a bunch of optimizations for jQuery landed after that, so I wonder if there's any difference between 25 and Nightly.
Sure. So the caveat is that I'm testing on Mac (64-bit, therefore) and we may care more about Windows 32-bit numbers here. But here's what I see for the "Final Score" number for this test: Firefox 22: 1466 Firefox 25: 4049 Today's nightly: 3730 Not sure why that last is slower, offhand.
Oh, and on the same machine as comment 6 I have: Chrome: 6248 Safari: 8626
One other note. For my own local build, I get 4017. Also, if I make HTMLDocument not be a proxy, that doesn't change performance here.
You need to log in before you can comment on or make changes to this bug.