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

¡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

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.

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

(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.

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.

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!

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