1524334 - Zooming in on Google Docs takes a long time

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[(no longer active)]

STR:

1. Go to a google docs page, such as https://docs.google.com/document/d/11hC7SzR5HS8Kw4KAfGZASZKaC0wPYIdZecuKPQrPT8I/edit (requires Mozilla LDAP, sorry!)
2. Zoom out to 90% and back in to 100%.
3. See the profile: http://bit.ly/2GfvChR. The zooming in part to a 100% takes a super long time. There is a setTimeout() that takes about 11 seconds on my machine.

Comment 1

[Jean Gong :jgong]

Ehsan, can you clarify what zoom menu you are referring to Firefox or gdoc zoom menu?

Comment 2

[Daniel Holbert [:dholbert]]

I captured a profile as well (on Linux, using full-page-zoom i.e. 'Ctrl -' and then 'Ctrl +'): https://perfht.ml/2RH9qPM

Like ehsan, my zoom-to-100% step also triggers a long settimeout handler, which causes a 12.9s red-bar processing delay.

Comment 3

[Daniel Holbert [:dholbert]]

(Also, FWIW, I gave it ~30 seconds to finish loading all of the 100+ pages in the google-doc before I tried to zoom, because I assume this issue depends on the large amount of content.)

Comment 4

[Daniel Holbert [:dholbert]]

It looks like we're spending a long time in JS (and AFAICT it's not js-calling-into-layout or anything like that -- only around 600ms total are spent with "reflow" in the stack, and around 200ms with "restyle" in the stack).

Comment 5

[(no longer active)]

(In reply to Jean Gong :jgong (OOO Dec 20 - Jan 8) from comment #1)

Ehsan, can you clarify what zoom menu you are referring to Firefox or gdoc zoom menu?

Firefox full page zoom.

Comment 6

[Daniel Holbert [:dholbert]]

I can reproduce this in Nightly on Windows 10, too, FWIW.

(We had some reports in the QF triage meeting that folks on non-linux platforms were having trouble reproducing, but now I'm wondering if perhaps they were just watching for the repaint [which happens quickly], rather than watching for the page to continue to be interactive, e.g. to respond appropriately to clicks that should change the blinking cursor's position. That's the easiest way I've been able to determine that the content process is hanging here, without editing the document.)

Comment 7

[Daniel Holbert [:dholbert]]

Here's my Win10 profile (in a fresh browser profile -- I was able to repro in my main profile too): https://perfht.ml/2RGGVBU

First half is my Ctrl - (to 90%), second half is my Ctrl + (back to 100%)

Comment 8

[Kannan Vijayan [:djvj]]

This is a weird profile to look at. There are a lot of restyles and reflows happening at very high frequency, not being recorded by the sampler. You can see them in the marker chart and visually, if you zoom in. They're not showing up in the samples, but the entire execution is littered with calls into DOM reflow and style code.

I suspect a significant amount of the overhead is going towards the overhead of the glue code between JS and the C++ DOM code. You can see this in the stack-chart where we are calling GenericMethod and GenericSetter calls (https://searchfox.org/mozilla-central/source/dom/bindings/BindingUtils.cpp#3076 and other code nearby).

Are these the fast-paths in the engine for calling out into C++ or can we do something better here?

Comment 9

[Jan de Mooij [:jandem]]

(In reply to Kannan Vijayan [:djvj] from comment #8)

I suspect a significant amount of the overhead is going towards the overhead of the glue code between JS and the C++ DOM code. You can see this in the stack-chart where we are calling GenericMethod and GenericSetter calls (https://searchfox.org/mozilla-central/source/dom/bindings/BindingUtils.cpp#3076 and other code nearby).

Are these the fast-paths in the engine for calling out into C++ or can we do something better here?

Ion can call the right Gecko C++ function directly (using JitInfo annotations) instead of going through the getter/setter/method bindings here, but on a page like this that's probably unlikely to matter much...