This is probably the best ticket to discuss improving the performance of LogConsole. Here is some additional context from PR#1105:
Many moons ago, I added some "batching" behavior to LogConsole that would sequentially call the render method using more and more log data, with the hope that React's DOM diffing could pretty quickly update the DOM by adding just the new rows. This would help reduce browser lock up when you threw it 10K+ log lines at once.
At some point the isLoading flag was introduced and it prevents any log elements from being returned from render while this log concat process was happening. This seems like an accident, as all it seems to do now is pause 500ms between some array concatenation but not actually render anything to the screen. The end result is that React tries to render 10k+ log lines all at once and the browser never seems to recover.
I experimented with removing the isLoading guard before the Array.map call for the log lines, so that the "batched rendering" could actually happen. The screen does update, but very very slowly. The browser is still responsive but there's a ton of lag while trying to scroll while new elements are being added. For a 50K line log file it took a couple of minutes or so to finish up. Eventually it does and you're able to scroll, still a bit laggy but much improved over that.
Some ideas:
- Get the batched rendering working again and play with the batch sizes (currently 500 lines, perhaps larger would be fine and actually speed things up)
- Rather then using arbitrary setTimeout to break up the batches, try adding a callback to setState and then using a smaller smaller delay (1000/60) to start the next batch
- Verify that setState/callback will still be supported by Fiber
- Or just use componentDidUpdate (per docs, the better choice)
- Determine if there's a hard limit to the number of the lines we should ever attempt to show
- Test whether the onClick handler for each line is creating a performance bottle neck, if so try providing a bound method rather than fat arrow function, if that doesn't work try adding a single click handler to the root element and doing a little event targeting or geometry to determine which line was clicked
- Realize that the batched rendering may complicate unit testing...
- Another option is to virtualize this control but it would cause serious issues for searching the log, unless we wanted to build our own UI to handle searching (like how google docs does)
This is probably the best ticket to discuss improving the performance of LogConsole. Here is some additional context from PR#1105:
Many moons ago, I added some "batching" behavior to LogConsole that would sequentially call the render method using more and more log data, with the hope that React's DOM diffing could pretty quickly update the DOM by adding just the new rows. This would help reduce browser lock up when you threw it 10K+ log lines at once.
At some point the isLoading flag was introduced and it prevents any log elements from being returned from render while this log concat process was happening. This seems like an accident, as all it seems to do now is pause 500ms between some array concatenation but not actually render anything to the screen. The end result is that React tries to render 10k+ log lines all at once and the browser never seems to recover.
I experimented with removing the isLoading guard before the Array.map call for the log lines, so that the "batched rendering" could actually happen. The screen does update, but very very slowly. The browser is still responsive but there's a ton of lag while trying to scroll while new elements are being added. For a 50K line log file it took a couple of minutes or so to finish up. Eventually it does and you're able to scroll, still a bit laggy but much improved over that.
Some ideas: