1486996 - Console slow reflows - OSX differences depending on Scrollbar visibility (Alway -> slow, other options -> less slow)

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[Nicolas Chevobbe [:nchevobbe]]

STR:
0. Go to about:blank
1. Open the console
2. Evaluate the following: 
```js
for (let i = 0; i < 500; i ++) {
  console.log(i)
}
```
3. When all the log are displayed, type `z` in the input (it shouldn't trigger an autocompletion so it won't pollute the profile)

---

Here's how it looks on my work machine (OSX 10.13.6): https://perfht.ml/2BXGm3V — 2 ~90ms reflows 
Here's how it looks on my personal, 9 years old machine (OSX 10.11.6): https://perfht.ml/2wmomuY — 2 _18ms_ reflows 

It's almost 5 times faster on my old laptop which is quite surprising to me.

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

For reference, this is is the same steps on FirefoxDevEdition: https://perfht.ml/2Nyk4Y4 (grid layout, <1ms reflows; we can't really use grid with the design we want now though)

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

Brad, can you make sense of the differences between OS versions in Comment 0 ?

Comment 3

[Brad Werth [:bradwerth]]

I'll investigate.

Comment 4

[Brad Werth [:bradwerth]]

Okay, at least part of this appears to be about the handling of scrollbars, and whether those scrollbars are visible or not. The slow profile spends a lot of time in a function that behaves differently whether or not the horizontal scrollbar is visible. So, one possible difference between your two machines might be some OS-level preference about when scrollbars should be shown. In current macOS, in System Preferences, the General tab has some options for scrollbars visible:

* Automatically based on mouse or trackpad
* When scrolling
* Always

On my current machine, I have "Always" set, and my guess would be that would provide the best performance since the size of overflow containers would never have to guess if an inline element would cause a horizontal scrollbar to appear. Check those settings on both of your machines (which of course might be different in the older version of macOS) and see if they affect your profile behavior. I'll do my own testing with this setting and see what they do on my machine.

Comment 5

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #4)
 
> On my current machine, I have "Always" set, and my guess would be that would
> provide the best performance...

Yes, this setting is very likely what is responsible for the difference in your two profiles. Against my prediction, I get much faster reflows with "When scrolling" is selected.

* "Always"         65ms (with a call pattern roughly matching your slow profile)
* "When Scrolling"  9ms (with a call pattern roughly matching your fast profile)

I'll try to figure out why the "Always" setting puts us in such a slow path for flex container layout and what we can do about it in the platform.

Comment 6

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #5)
> I'll try to figure out why the "Always" setting puts us in such a slow path
> for flex container layout and what we can do about it in the platform.

Sorry, to be clear, this slow path is in the nsHTMLScrollFrame::ReflowContents method. The use of flex within the scroll frame may be incidental.

Comment 7

[Brad Werth [:bradwerth]]

Attachment: Bug 1486996 Part 1: Make nsHTMLScrollFrame::ReflowContents smarter about next steps when ::TryLayout fails.

Comment 8

[Brad Werth [:bradwerth]]

The proposed patch should speed up some nsHTMLScrollFrame::ReflowContents calls, but didn't speed up this one for reasons I don't understand yet.

Comment 9

[Nicolas Chevobbe [:nchevobbe]]

I confirm the difference in those options between my 2 machines.
Thanks a lot Brad !
Also, I tried setting overflow: hidden to the element that shouldn't overflow and I'm now closer to ~50ms reflows (in comparison to ~90ms prior to that).

Comment 10

[Brad Werth [:bradwerth]]

There's not much more to do on this issue, I think. We've figured out what is causing the differences in the two profiles. The fact that the flex container itself is a slow reflow is covered in Bug 1482798 which I've reopened and updated with my new understanding of next steps. The patch I wrote for this bug should be put into its own bug, which I will do. That patch doesn't affect this issue since the reflow call pattern here reflows the minimum two times: once without a vertical scrollbar and once with. The proposed patch can't improve on that, though it could improve performance for other cases.