Open Bug 940813 Opened 9 years ago Updated 3 years ago

Browsermark "DOM Advanced Search" is 1.6x slower than Chrome


(Core :: JavaScript Engine, defect)

Not set




(Reporter: cpeterson, Unassigned)


(Blocks 1 open bug)


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.
Component: General → DOM
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
* 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
* 5% is str_replace; almost half is self time in that function and the rest is smeared
     across RegExpShared::execute, RegExpShared::executeMatchOnly, and
* 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.
Component: DOM → JavaScript Engine
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.

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.
Depends on: 1094255
You need to log in before you can comment on or make changes to this bug.