1104898 - Browsermark "DOM Create Source" test slower than Chrome and Safari

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

Chrome is 1.7x faster, Safari 2.8x.

Will post more info.

Comment 1

[Jan de Mooij [:jandem]]

Attachment: Standalone testcase

Comment 2

[Jan de Mooij [:jandem]]

If I comment out the actual code in the "run" function, I get the following scores:

Nightly: ~100000
Chrome:  ~100000
Safari:  ~250000

So the harness itself is much faster in Safari... I want to investigate this too.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Why am I seeing all minorGC things in Nightly.
I would expect SetInnerHTML to take lots of time, but no.

I get better results in Aurora.
Is this partially about the GC issue (bug 1103593 )?

Comment 4

[Jan de Mooij [:jandem]]

In external.libs.js there's a minified jQuery SVG library:

/* http://keith-wood.name/svg.html
 SVG for jQuery v1.4.5.
...

If I comment this line out, I get the following scores:

Nightly: 12658 (was 2000-3000)
Chrome:  17391 (was 4000-5000)
Safari:  21739 (was 8000-9000)

So this SVG thing affects the score *a lot* :( We should find out what it's doing exactly...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Removing that one line makes the next line ("SVG attribute animations") throw.  If I comment _that_ line out too, the score goes back to the lower value.  So the real question is what the "SVG attribute animations" line does.  Sorta.  Because I get more exceptions later on with that commented out...

Anyway, if I comment out all of external.libs.js then I get the higher score with no exceptions.  So something in there is doing something.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So I tried removing the following, starting at the end, from the external.libs.js: Knockout, Ember, Backbone, Underscore.  That does not change the score (still with no exceptions).

If I then remove Angular, the score shoots up.  If I leave Angular but remove everything else in the file, the score stays low.

So I think it's something Angular is doing.

Comment 7

[Boris Zbarsky [:bzbarsky]]

The relevant unminified version of AngularJS is at https://code.angularjs.org/1.1.5/

Comment 8

[Boris Zbarsky [:bzbarsky]]

And in particular, it's this call:

  $('div#hidden_playground_3').remove()

I see this take about 600ms when AngularJS is being used and about 25ms otherwise (in Firefox).

And this happens because https://code.angularjs.org/1.1.5/angular.js at line 1593 or so does:

  // jQuery mutation patch
  //
  //  In conjunction with bindJQuery intercepts all jQuery's DOM destruction apis and fires a
  // $destroy event on all DOM nodes being removed.

So it sounds like this bit of AngularJS is completely dominating the benchmark.  We should probably let browsermark know about this or something; I doubt they intended to just time the teardown there.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Looking at the removePatch() function there, I would expect the time it takes to be some combination of the DOM traversal and the triggerHandler and jQuery-wrapping.

In practice, according to the Gecko profiler it's:

33% doing the trigger() thing.  This looks like pure JS stuff; using a non-minified jQuery would probably produce more info here.

40% doing minor GCs; all of this time is gc::StoreBuffer::MonoTypeBuffer<SlotsEdge>::mark calling MarkArraySlots and then time spent under there.

10% or so under jQuery's cleanData().  Some DOM bits in there (e.g. nodeType gets, not via Ion fast paths for some reason), property deletion, etc.

3-4% memmoving array elements when shift() is called.

and some long-tail stuff.

Comment 10

[Boris Zbarsky [:bzbarsky]]

One other note.  Newer versions of Angular seem to have a much smaller hit here, and we're faster than Chrome on the newer Angular versions... so if I just update the Angular version the testcase uses we end up faster than Chrome.

Comment 11

[Emanuel Hoogeveen [:ehoogeveen]]

(In reply to Please do not ask for reviews for a bit [:bz] from comment #9)
> 40% doing minor GCs; all of this time is
> gc::StoreBuffer::MonoTypeBuffer<SlotsEdge>::mark calling MarkArraySlots and
> then time spent under there.

This sounds somewhat similar to what Terrence described in bug 1103593 comment #2 (if I understood it correctly). needinfo?ing him since GGC is implicated regardless.

Comment 12

[Jan de Mooij [:jandem]]

(In reply to Please do not ask for reviews for a bit [:bz] from comment #10)
> so if I
> just update the Angular version the testcase uses we end up faster than
> Chrome.

Still slower than Safari right? Initially I tried to create a minimal testcase with just the .append(...) part in a loop and we were about as fast as Chrome or faster, but Safari was still ahead.

(In reply to Please do not ask for reviews for a bit [:bz] from comment #8)
> So it sounds like this bit of AngularJS is completely dominating the
> benchmark.  We should probably let browsermark know about this or something;
> I doubt they intended to just time the teardown there.

Yes. Both Browsermark and Peacekeeper are terrible unfortunately :(

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Still slower than Safari right?

Yes.  Even than Safari 7.1 (though that has about the same performance as a WebKit nightly does).

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

The GC part is really bad here.

Comment 15

[Naveed Ihsanullah [:naveed]]

I informed RightWare about the destroy event in AngularJS dominating the profile

Comment 16

[Terrence Cole [:terrence]]

Looks like Jon is already ni?ed.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

This is an ancient bug. Firefox is a bit slower than Chromium but the testcase does cause quite some errors, so I wouldn't trust the results.