Bugzilla

(retriaging "flexbox-perf-bugs" dependencies)

Here's a profile I captured of this today (following STR from comment 0, except using the Web Console instead of the Scratchpad since the scratchpad isn't a thing anymore):
https://share.firefox.dev/3fmCmZw

(Note: I had to close the tab in order to be able to capture a profile and to avoid letting the runaway logging completely lock up the browser.)

Observations:
 - Focusing on 0-30s (which I thinks is the time up until I closed the tab), there are repeated "batches of work", with each batch progressively more time-consuming than the previous one.  (As I recall, this may be due to some webconsole behavior where we clamp the amount of log output, and we repeatedly double the clamp-limit over time, or something like that?)

 - The reflow/restyle time in the longer batches is substantial, but the vast majority of the time is JS (E.g. in the last/longest batch from  12s-27s, we do 1.2s of reflow and 500ms of restyle at the very end, after ~13 seconds of JS/DOM operations)

 - I would guess that this growing reflow/restyle time is consistent with the growing amount of content that we're logging per-"batch".

Conclusion: it doesn't look like the reflow performance here is a significant part of the jank to narrow in on -- and it seems consistent with what I might expect from churning out progressively-larger batches of log lines to be laid out all at once.

To really address this bug, I think we would need to focus in on the more expensive things that are happening in the profile; and to improve the relatively-small-part that is the layout performance, I think we would probably want a frontend change in the web console (stricter clamping on the number of lines that can be logged at once, for example; and/or stricter clamping on the upper limit of lines that we'll allow to be shown; or some sort of virtual impl that only attempts to lay out some upper-limit number of lines.)

So: I'm dropping the "flexbox-perf-issues" dependency since it's not clear that there's a flexbox perf problem to be addressed here, at this point.  (There may be one for other webconsole bugs, but I'm not seeing one here; as noted above, the reflow times seem consistent with giant amounts of content being added at once and needing to be laid out.)

(retriaging "flexbox-perf-issues" dependencies)

Here's a profile I captured of this today (following STR from comment 0, except using the Web Console instead of the Scratchpad since the scratchpad isn't a thing anymore):
https://share.firefox.dev/3fmCmZw

(Note: I had to close the tab in order to be able to capture a profile and to avoid letting the runaway logging completely lock up the browser.)

Observations:
 - Focusing on 0-30s (which I thinks is the time up until I closed the tab), there are repeated "batches of work", with each batch progressively more time-consuming than the previous one.  (As I recall, this may be due to some webconsole behavior where we clamp the amount of log output, and we repeatedly double the clamp-limit over time, or something like that?)

 - The reflow/restyle time in the longer batches is substantial, but the vast majority of the time is JS (E.g. in the last/longest batch from  12s-27s, we do 1.2s of reflow and 500ms of restyle at the very end, after ~13 seconds of JS/DOM operations)

 - I would guess that this growing reflow/restyle time is consistent with the growing amount of content that we're logging per-"batch".

Conclusion: it doesn't look like the reflow performance here is a significant part of the jank to narrow in on -- and it seems consistent with what I might expect from churning out progressively-larger batches of log lines to be laid out all at once.

To really address this bug, I think we would need to focus in on the more expensive things that are happening in the profile; and to improve the relatively-small-part that is the layout performance, I think we would probably want a frontend change in the web console (stricter clamping on the number of lines that can be logged at once, for example; and/or stricter clamping on the upper limit of lines that we'll allow to be shown; or some sort of virtual impl that only attempts to lay out some upper-limit number of lines.)

So: I'm dropping the "flexbox-perf-issues" dependency since it's not clear that there's a flexbox perf problem to be addressed here, at this point.  (There may be one for other webconsole bugs, but I'm not seeing one here; as noted above, the reflow times seem consistent with giant amounts of content being added at once and needing to be laid out.)