1448672 - [css-flexbox] https://ci.chromium.org/p/chromium/g/main/console?limit=500 takes very long to load and hangs the content process on Sync reflow

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Mayank Bansal]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180325100345

Steps to reproduce:

1. Create fresh profile on nightly
2. go to https://ci.chromium.org/p/chromium/g/main/console?limit=500



Actual results:

Page will not stop loading even after several minutes
The content process is using 100% CPU
You cannot interact with the page at all


Expected results:

not so
chrome also takes some time to load this page. But it takes some 10-15 seconds
Nightly takes several minutes, and it hadnt still loaded

https://perfht.ml/2G5Qqtz

Comment 1

[Mayank Bansal]

Attachment: aboutsupport.txt

Comment 2

[alex_mayorga]

¡Hola!

Yup! Confirming on Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 ID:20180325130758

Here's another profile FWIW https://perfht.ml/2pCUwyU

¡Gracias!
Alex

Comment 3

[Mayank Bansal]

from the profile, it looks like most of the time is spent in sync reflows in nsFlexContainerFrame::GetPrefISize and nsFlexContainerFrame::GetMinISize

tentative ni? based on FlexContainer.

Comment 4

[Mats Palmgren (inactive)]

It should be pretty easy to cache GetMinISize/GetPrefISize like we do
in nsGridContainerFrame.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren (:mats) from comment #4)
> It should be pretty easy to cache GetMinISize/GetPrefISize like we do
> in nsGridContainerFrame.

I've got patches to do this ^^, and I'm going to spin them off to a helper bug (bug 1454822), because -- while they help a lot -- they don't get us up to Chrome's neighborhood of performance (~15 second pageload per comment 0), so I don't want to close this bug when we land just these patches.

But bug 1454822's caching will help a lot here! Here's a before/after comparison, for bug 1454822's forthcoming patches, in a local opt build.

Before: https://perfht.ml/2vkAEpG
  * After ~185 seconds of loading, the load still hasn't finished.
  * The periodic script-triggered sync reflows are each 388-450ms
  * nsFlexContainerFrame::Get is in the stack for 103 seconds (out of 184 total seconds in reflow), 56% of our cumulative reflow time.

After: https://perfht.ml/2HprRHR
 * Pageload takes ~55 seconds altogether (52 seconds of which is in reflow)
 * The periodic script-triggered sync reflows are each 100-110ms long (1/4th as long!)
 * nsFlexContainerFrame::Get is in the stack for only 131ms (out of 52 seconds in reflow), representing a quarter of 1 percent of our cumulative reflow time.

Comment 6

[Mayank Bansal]

I tried on the latest nightly, and the page opens in less than 10seconds for me. Same or faster than chrome. I even tried extreme versions of the page like https://ci.chromium.org/p/chromium/g/main/console?limit=2000 and it loaded fine.

Not sure why you got the timing mentioned in comment 5.
(Did you had WR enabled? One time I got the page in permanently busy state with WR.  Didnt repro again, so considering it as a fluke? )

I wouldn't mind calling this bug fixed, if you dont see any other low-hanging fruit here, and can repro the fast page loading.

Comment 7

[Daniel Holbert [:dholbert]]

Oh, wow! I'm seeing results similar to what you describe, yeah -- the page loads quite fast now, definitely less than 10 seconds.

I suspect that in comment 5, my "post-patch" tree might've been a debug build (which would have a good deal more overhead / less optimization) - that would explain my slower results there.

Let's call this FIXED by bug 1454822 then.  Thanks for the report and for verifying that the fix helped!

Comment 8

[Daniel Holbert [:dholbert]]

(Calling this "verified" due to independent confirmation in Nightly, between comment 6 / comment 7.)