The VanillaJS part of Speedometer adds items to the TODO list by building up a string for all TODO items so far, and then assigns it to innerHTML. We spend quite a lot of time doing this innerHTML set. For the attached standalone testcase I get the following numbers (this seems to match the time we spend on this on the original test): Safari: 36 ms Chrome: 40 ms Nightly: 60-70 ms After bug 1346723 and bug 1347489 are fixed, this will be the main reason we're slower than Chrome on the VanillaJS/Adding100Items subtest.

(In reply to Jan de Mooij [:jandem] from comment #0) > After bug 1346723 and bug 1347489 are fixed, this will be the main reason > we're slower than Chrome on the VanillaJS/Adding100Items subtest. Well scratch the first part, this is the main reason we're slower even without these bugs fixed.

I wonder if this is related to https://bugzilla.mozilla.org/show_bug.cgi?id=1022239#c1 /me builds a new opt build and profiles.

Btw, the profiles hint that Speedometer is still super silly benchmark from DOM point of view. It is testing normally rarely run code paths.

FWIW, at least on my machines we're on par with Chrome on Linux and Android, but behind on Windows. Don't have OSX to test, but I was told we're behind there too. Bug 1347737 will hopefully help there.

With bug 1347737 fixed we seem to be about on par with Chrome on Mac. But about 2x slower than Safari....

Not allocating HTML5StackNodes all the time should help a bit. And bug 1351857 has perhaps still something to do and bug 1347643. (not so sure about bug 1350885)

Still slower than Chrome on Windows. (Faster on Linux and Android)

(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #5) > With bug 1347737 fixed we seem to be about on par with Chrome on Mac. But > about 2x slower than Safari.... It's definitely better than before for me on Mac, but I loaded it a times in Chrome (both stable and canary) and I get 44-50 ms, whereas Nightly is more like 50-55 ms, so we're close but still somewhat slower. Hopefully the bugs that are still open will shave off a couple more ms :)

I think the stuff listed in comment 6 might be enough. (bug 1355441 filed about HTML5StackNodes)

Random note, Edge is more than 3x slower than Gecko.

browser.dom.window.dump.enabled needs to enabled.

On the Quantum Flow reference laptop (Win10) I see Nightly (64bit) taking ~60ms and Chrome 58 taking around ~59ms, at best. I'm hoping bug 1355441 will help still a bit. For some reason Chrome Canary (60) is significantly slower. Perhaps they have some assertions or such there which are dropped from release versions.

I get now similar results in Nightly as in Chrome on Windows, and on Linux we're faster. Jandem mentioned we're perhaps still a bit slower on Mac, but not much. bug 1355441 will hopefully still help a bit. This bug is now about the comparison to Chrome, Bug 1364861 is about Safari. Hopefully someone familiar with Instruments and easy access to a Mac could do some profiling there. Marking this optimistically fixed. Feel free to reopen if needed.

Modified version of above testcase with the following ergonomic improvements: * Printing to the web console rather than the terminal. * Tracking/printing the average * Not loading the non-existent scripts.