[I'm doing a retriage of flexbox-perf-bug dependencies to see which ones are still a problem.] The sqlite URL from comment 6 doesn't work anymore (the file moved/disappeared), but here's the modern version of the same file, I think (6000 lines long): https://source.chromium.org/chromium/chromium/src/+/master:third_party/sqlite/src/src/expr.c Here's a profile I captured of that pageload, in current Nightly (filtered for `DoReflow`): https://share.firefox.dev/3dSZ2QS The metrics are similar to comment 6: - 367ms total spent in ::DoReflow - The longest individual reflow is 191ms HOWEVER - I **also** captured a profile in Chrome 83, and they have pretty much the exact same results! Here's my Chrome profile (on the "marker chart" tab, filtered for "Layout"). Look at the second row in the marker chart, for Layout (not the other LayoutFooBar rows): https://share.firefox.dev/3e4mwCU Observations: - Their longest layout event is 191ms (exactly the same as in my Firefox profile). - They have a long tail of shorter-but-still substantial reflows as you seek backwards from that one (in reverse order, their durations are 191, 56, 21, 16, 22, and then there are some that are on the order of 1-2ms.) These sum to 306ms (not including the short 1-2ms ones). - So their total amount of time spent in reflow is in the same ballpark as in Firefox, and their longest reflow is the same duration as in Firefox. So, to the extent that there's layout jank here, it's cross-browser layout jank and hence is probably attributable to the site (& just problems inherent with large amounts of content), and not to a Firefox-specific bug. So I think we can call this WORKSFORME -- smaug, what do you think? (Perhaps you could sanity-check me and see if you're seeing a noticeable difference between Firefox and Chrome on your machine?)
Bug 1288563 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
[I'm doing a retriage of flexbox-perf-bug dependencies to see which ones are still a problem.] The sqlite URL from comment 6 doesn't work anymore (the file moved/disappeared), but here's the modern version of the same file, I think (6000 lines long): https://source.chromium.org/chromium/chromium/src/+/master:third_party/sqlite/src/src/expr.c Here's a profile I captured of that pageload, in current Nightly (filtered for `DoReflow`): https://share.firefox.dev/3dSZ2QS The metrics are similar to comment 6: - 367ms total spent in ::DoReflow - The longest individual reflow is 191ms HOWEVER - I **also** captured a profile in Chrome 83, and they have pretty much the exact same results! Here's my Chrome profile (on the "marker chart" tab, filtered for "Layout"). Look at the second row in the marker chart, for Layout (not the other LayoutFooBar rows): https://share.firefox.dev/3e4mwCU Observations: - Their longest layout event is 191ms (exactly the same as in my Firefox profile). - They have a long tail of shorter-but-still substantial reflows as you seek backwards from that one (in reverse order, the Layout-event durations are 191, 56, 21, 16, 22, and then there are some that are on the order of 1-2ms.) These sum to 306ms (not including the short 1-2ms ones). - So their total amount of time spent in reflow is in the same ballpark as in Firefox, and their longest reflow is the same duration as in Firefox. So, to the extent that there's layout jank here, it's cross-browser layout jank and hence is probably attributable to the site (& just problems inherent with large amounts of content), and not to a Firefox-specific bug. So I think we can call this WORKSFORME -- smaug, what do you think? (Perhaps you could sanity-check me and see if you're seeing a noticeable difference between Firefox and Chrome on your machine?)
[I'm doing a retriage of flexbox-perf-bug dependencies to see which ones are still a problem.] The sqlite URL from comment 6 doesn't work anymore (the file moved/disappeared), but here's the modern version of the same file, I think (6000 lines long): https://source.chromium.org/chromium/chromium/src/+/master:third_party/sqlite/src/src/expr.c Here's a profile I captured of that pageload, in current Nightly (filtered for `DoReflow`): https://share.firefox.dev/3dSZ2QS The metrics are similar to comment 6: - 367ms total spent in ::DoReflow - The longest individual reflow is 191ms HOWEVER - I **also** captured a profile in Chrome 83, and they have pretty much the exact same results! Here's my Chrome profile (on the "marker chart" tab, filtered for "Layout"). Look at the second row in the marker chart, for Layout (not the other LayoutFooBar rows): https://share.firefox.dev/3e4mwCU Observations: - Their longest layout event is 191ms (exactly the same as in my Firefox profile). - They have a long tail of shorter-but-still substantial reflows as you seek backwards from that one (in reverse order, the Layout-event durations are 191, 56, 21, 16, 22, and then there are some that are on the order of 1-2ms.) These sum to 306ms (not including the short 1-2ms ones). - So their total amount of time spent in reflow is in the same ballpark as in Firefox (367ms vs. 306ms-plus-some-fudge-factor-for-a-bunch-of-small-layouts), and their longest reflow is the same duration as in Firefox. So, to the extent that there's layout jank here, it's cross-browser layout jank and hence is probably attributable to the site (& just problems inherent with large amounts of content), and not to a Firefox-specific bug. So I think we can call this WORKSFORME -- smaug, what do you think? (Perhaps you could sanity-check me and see if you're seeing a noticeable difference between Firefox and Chrome on your machine?)
[I'm doing a retriage of flexbox-perf-bug dependencies to see which ones are still a problem.] The sqlite URL from comment 6 doesn't work anymore (the file moved/disappeared), but here's the modern version of the same file, I think (6000 lines long): https://source.chromium.org/chromium/chromium/src/+/master:third_party/sqlite/src/src/expr.c Here's a profile I captured of that pageload, in current Nightly (filtered for `DoReflow`): https://share.firefox.dev/3dSZ2QS The metrics are similar to comment 6: - 367ms total spent in ::DoReflow - The longest individual reflow is 191ms HOWEVER - I **also** captured a profile in Chrome 83, and they have pretty much the exact same results! Here's my Chrome profile (on the "marker chart" tab, filtered for "Layout"). Look at the second row in the marker chart, for Layout (not the other LayoutFooBar rows): https://share.firefox.dev/3e4mwCU Observations: - Their longest layout event is 191ms (exactly the same as in my Firefox profile). - They have a long tail of shorter-but-still substantial reflows as you seek backwards from that one (in reverse order, the Layout-event durations are 191, 56, 21, 16, 22, and then there are some that are on the order of 1-2ms.) These sum to 306ms (not including the short 1-2ms ones). - So their total amount of time spent in reflow is in the same ballpark as in Firefox (367ms vs. 306ms-plus-some-fudge-factor-for-a-bunch-of-small-layouts-that-I-didn't-bother-adding-up), and their longest individual reflow is the same duration as in Firefox (191ms). So, to the extent that there's layout jank here, it's cross-browser layout jank and hence is probably attributable to the site (& just problems inherent with large amounts of content), and not to a Firefox-specific bug. So I think we can call this WORKSFORME -- smaug, what do you think? (Perhaps you could sanity-check me and see if you're seeing a noticeable difference between Firefox and Chrome on your machine?)