1347525 - Setting innerHTML slower than in Chrome

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement, P1)

Description

[Jan de Mooij [:jandem]]

Attachment: Testcase

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.

Comment 1

[Jan de Mooij [:jandem]]

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

Comment 2

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

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.

Comment 3

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

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

Comment 4

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

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

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

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)

Comment 7

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

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

Comment 8

[Jan de Mooij [:jandem]]

(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 :)

Comment 9

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

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

Comment 10

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

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

Comment 11

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

Attachment: testcase running in a loop, dumping to terminal

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

Comment 12

[Julian Seward [:jseward]]

Attachment: testcase running in a loop, dumping to terminal, and showing best time so far and also iteration count

Comment 13

[Julian Seward [:jseward]]

Attachment: testcase running in a loop, 200 iters, dumping to terminal, and showing best time so far

Comment 14

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

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.

Comment 15

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

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.

Comment 16

[Bobby Holley (:bholley)]

Attachment: bug1347525testcase_looping3.html

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.