Setting innerHTML slower than in Chrome

RESOLVED FIXED

Status

()

enhancement
P1
normal
RESOLVED FIXED
2 years ago
2 months ago

People

(Reporter: jandem, Unassigned)

Tracking

(Blocks 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qf:p1])

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

2 years ago
Posted file 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.
(Reporter)

Comment 1

2 years ago
(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.
Depends on: 1347634
Depends on: 1347639
Depends on: 1347640
Btw, the profiles hint that Speedometer is still super silly benchmark from DOM point of view. It is testing normally rarely run code paths.
Depends on: 1347643
Whiteboard: [qf:p1]
Priority: -- → P1
Depends on: 1350885
Depends on: 1351303
Depends on: 1351857
Depends on: 1351860
Depends on: 1352235
Depends on: 1352687
Depends on: 1352898
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)
(Reporter)

Comment 8

2 years ago
(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)
Depends on: 1355441
Random note, Edge is more than 3x slower than Gecko.
browser.dom.window.dump.enabled needs to enabled.
Attachment #8864540 - Attachment mime type: text/plain → text/html
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.
Blocks: 1364861
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Summary: Setting innerHTML slower than in Chrome/Safari → Setting innerHTML slower than in Chrome

Updated

2 years ago
No longer blocks: TimeToFirstPaint_FB
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.
Depends on: 1398119
(Assignee)

Updated

2 months ago
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.