Open
Bug 1104898
Opened 10 years ago
Updated 1 year ago
Browsermark "DOM Create Source" test slower than Chrome and Safari
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
NEW
People
(Reporter: jandem, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Chrome is 1.7x faster, Safari 2.8x. Will post more info.
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
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•10 years ago
|
||
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 )?
Reporter | ||
Comment 4•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
The relevant unminified version of AngularJS is at https://code.angularjs.org/1.1.5/
Comment 8•10 years ago
|
||
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.
Flags: needinfo?(nihsanullah)
Comment 9•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
(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.
Flags: needinfo?(terrence)
Reporter | ||
Comment 12•10 years ago
|
||
(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•10 years ago
|
||
> Still slower than Safari right?
Yes. Even than Safari 7.1 (though that has about the same performance as a WebKit nightly does).
Comment 15•9 years ago
|
||
I informed RightWare about the destroy event in AngularJS dominating the profile
Flags: needinfo?(nihsanullah)
Comment 17•3 years ago
|
||
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.
Flags: needinfo?(jcoppeard)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•