In the webconsole in a local build, if I enter this command: for(var i = 0; i < 1000; i++) { console.log(i) } I get a couple of slow reflows that appear to be due to flex layout (one is 64ms, one is 253ms): https://perfht.ml/2kKImnu. I'm mostly interested in making the console faster, so may end up looking for alternate CSS to use instead, but I'd prefer to keep using flexbox if this can be optimized.

I would bet this is similar to bug 1377253 and bug 1376536. See bug 1377253 comment 0 in particular. I'm hoping to fix that bug soon, which should make cases like this faster. In the meantime, though, the best way to avoid this performance issue is to avoid reflowing too many display:flex subtree-roots at once (and avoid reflowing a display:flex element that has manymany children) -- because each such operation will reflow all of the flex container's children even if they haven't changed. (If the child subtree doesn't have dirty bits set, then that reflow may be fast; but if it's flex all the way down, then it probably won't be.) e.g. locally, it looks like I get a bit of a speedup if I remove "display:flex" from the .message{} CSS rule (though that breaks the layout, too).

We ended up working around this particular issue in Bug 1400176 by removing flex from the body element. I filed a new bug that happens during resize (Bug 1408190), which may have the same root cause as what we are seeing here but with different STR. Feel free to dupe if so. The test case in that bug should be a lot easier to work with, since we have a reduced testcase that loads in a tab instead of opening the devtools toolbox.

(In reply to Brian Grinstead [:bgrins] from comment #2) > I filed a new bug that happens during resize (Bug 1408190) Probably not supposed to be a self-reference, so I think this meant to say bug 1410464.

I assume this was fixed by Bug 1490890 in the same way as https://bugzilla.mozilla.org/show_bug.cgi?id=1482798#c29.