(In reply to Ting-Yu Lin [:TYLin] (UTC-7) from comment #11)
I'm trying to use mozrgression to capture a profile on my end. I'm looking at the second (longest)
nsColumnSetFrame::Reflow in both profiles in the "Flame graph" tab.
- Firefox 78 (2020-05-15) https://share.firefox.dev/3kTfcO9. The first and second
nsColumnSetFrame::Reflow takes 19ms and 592ms.
- Firefox 81 (2020-08-16) https://share.firefox.dev/348C9XN. The first and second
nsColumnSetFrame::Reflow takes 64ms and 319ms. (Not sure why the green
posix_fallocate in graphic category take near 1 minute on current nighty)
I profiled both build a few times, and the longest
nsColumnSetFrame::Reflow take roughly the same amount of time each time, about 5xx ms (2020-05-15) and 3xx ms (2020-08-16). I'm sure compared to Chrome, Firefox can be slower to layout multicol, but I'm skeptical that the slowness is because of bug 1647332.
Bas, could you help take a look at the profiles I captured, and see if I misinterpreted the data?
What's up with that 1s rasterize on the second profile?
Mind you, I was looking at Windows, which doesn't show these weirdly long reflows. It's pretty hard to compare your first and second profile, but most certainly both have really long reflows (I didn't see a really long reflow in 78, but I only ran 78 a couple of times, it could be a coincidence). Although the 78 reflow on a whole is 'considerably faster' than the 81 reflow. (n=1, and we appear to be seeing different frames in both profiles so this could be a coincidence)
As for bug 1647332, I'm not claiming it's necessarily related to this :). That was Emilio's first guess I think. But this reflow duration is most definitely problematic. I don't know enough about layout to make a guess as to another cause.