Performance degrades if you leave the browser console open
Categories
(DevTools :: Console, defect, P2)
Tracking
(Not tracked)
People
(Reporter: jesup, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
268.75 KB,
image/png
|
Details |
I left the Browser Console open, and had it logging JS GC/CC's ( javascript.options.mem.log which is a fair amount of logging, but not excessive).
I noticed the entire browser was sluggish, and a profile shows this:
https://share.firefox.dev/3HHmZZN
Basically, the console was using 100% of the Parent process, for layout, JS, and GC.
Closing the window resolves it
Updated•2 years ago
|
Updated•2 years ago
|
Comment 1•2 years ago
|
||
2 things seems to stand out:
- long reflows ( > 100ms , e.g. https://share.firefox.dev/3K58f9l). I know we did some work in the past to try to keep those acceptable, so maybe something regressed?
- long GCs in React (https://share.firefox.dev/3FptEXh), not sure how we can act on those for now
Updated•2 years ago
|
Comment 2•2 years ago
|
||
I can easily reproduce by evaluating this in the console (in a regular web page console):
for(var i=0; i < 100000; i++) {console.log("foo", {bar: true, plop: "hey"}, new Array(1000).join(" "));}
This will force creating 10000 messages, reaching the limit of number of messages displayed.
Then, running a single console.log("foo")
is significantly slow.
I imagine there is various micro optimizations we could do to make the reflows faster.
But rendering 10 000 elements with non-trivial DOM/CSS layout will possibly always be somehow slow.
I have the feeling that we once again hit the limitation of not having a viewport.
I think that's the way to make the console fast no matter how many messages are actually displayable.
Another option would be to lower the maximum number of messages being displayed...
but that may become an issue when debugging very verbose websites.
Comment 3•2 years ago
|
||
We could only show the last 500 or 1000 messages, and then when/if the user scrolls up, we'd load 500/1000 more (or a button with "load previous messages"). So it wouldn't be virtualization, but more "loading on demand".
Comment 4•2 years ago
|
||
jesup, in case you're being annoyed by this too much, you might want to try the multi line editor mode.
I did some quick testing and the layout are way less important in this mode.
I'll investigate the "regular" layout to see what can be improved as well
Comment hidden (spam) |
Updated•2 months ago
|
Description
•