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

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Chris Peterson [:cpeterson]]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is there a way I can get access to the source of this test?

Comment 2

[Chris Peterson [:cpeterson]]

(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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, and we should figure out why we have that js::GetProperty stubcall!

Comment 5

[Jan de Mooij [:jandem]]

(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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Oh, and on the same machine as comment 6 I have:

Chrome: 6248
Safari: 8626

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.