1473110 - slow reflows when typing in to a long compose-message body at Google Inbox

Status: RESOLVED WONTFIX

(Core :: Layout, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Log in to Google Inbox ( https://inbox.google.com/ ) with a google account.
 2. Click the red "+" to start composing a new message.
 3. Paste in 10 copies of the Mozilla Manifesto (or some other large body of text).
(I copypasted from the "Introduction" heading text at the top, down to "reality." at the end, from https://www.mozilla.org/en-US/about/manifesto/details/ ) 
 4. Start profiling.
 5. Start typing as fast as you can for 10-11 seconds.
 6. Stop profiling.

ACTUAL RESULTS:
Here's my profile, filtered for "Reflow": https://perfht.ml/2INZdwE

Observations:
 - Total time spent in reflow (over this ~11 second profile) was 1.9 seconds, so ~17%
 - Zooming in on a chunk towards the end (and hovering on & above the colorful blue "reflow" bar), we can see that the reflows are 10-11ms long, and refresh driver ticks are 20-23ms long.
 - Based on trying this a few times with varying amounts of content, the reflow time seems to increase with the amount of text that's been entered so far. (hence, STR step 3, to make the costs noticable here.)


EXPECTED RESULTS:
We'd like refresh driver ticks to be under 16ms and reflows to not occupy a significant portion of that, for small changes like character entry into this compose-message field.


(Note: I'm spinning this off of bug 1418145 since I don't know precisely what the STR were there, and the results aren't quite as bad as the ones reported over there.)

Comment 1

[Daniel Holbert [:dholbert]]

I captured my profile with latest linux Nightly: 63.0a1 (2018-07-03) (64-bit)

Comment 2

[Daniel Holbert [:dholbert]]

Flexbox is in the reflow backtrace, so bug 1377253 might help here.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: 10 copies of mozilla manifesto, for convenient copypasting into compose box for STR

For convenient testing reproducibility: here's the full text (10 copies of mozilla manifesto) that I pasted into my compose-email box in STR step 3.

Comment 4

[Daniel Holbert [:dholbert]]

Note: per https://twitter.com/inboxbygmail/status/1039952354450309121 and https://support.google.com/inbox/answer/9117840 ,  Google Inbox is being decommissioned, so this particular scenario is less of a priority now.

Comment 5

[Daniel Holbert [:dholbert]]

Inbox is slated to be decomissioned in March 2019 (in ~2 months). While it's still up, I did a comparison of this bug's STR between inbox & gmail, and it looks like gmail is a good bit better here.

Here's 2 profiles for each, filtered for "reflow". (When capturing these profiles, I pasted in the attached 10-copies-of-manifesto blurb, and then I started profiling, and then I held down my "a" key for ~10 seconds to type as many "a" characters as possible.)

Inbox:
https://perfht.ml/2VL0v2V 1.547 seconds
https://perfht.ml/2VLsGPA 1.267 seconds

Gmail (the current "new gmail" UI with material design etc):
https://perfht.ml/2VI8Xjz 0.481 seconds
https://perfht.ml/2VIGzOn 0.544 seconds

So it looks like gmail is a lot better here. I confirmed that by zooming in, too.

• If I zoom in on an inbox profile, I see reflow taking ~6ms to 11ms per refresh driver tick. E.g. here's a snippet with three long ones: https://perfht.ml/2VR6xPQ

• But for gmail, reflow is only 0.5-1ms per refresh driver tick, e.g. here: https://perfht.ml/2VLtRP0

Conclusion: this bug still seems to kinda exist for Inbox, but does not happen for Gmail, happily.

So, given that Inbox is going away very soon (and its "new gmail" replacement is unaffected), let's call this particular issue WONTFIX. To the extent that this same performance issue exists elsewhere on the web, we can track it in separate bugs.