Follow up from #131 (comment)

It looks like refresh and the layout is still taking far too long in a real application scenario. Consider the following portion of a Chromium timeline when running ls -lR /usr/share in VS Code, which takes around 3.5s for the process to run but ~25s until it's finished in the UI.

My initial thoughts on this were that it was taking too long to parse the incoming data in Terminal.prototype.write but this timeline seems to refute that. All time is spent in refresh and functions/events it triggers.

Here is the timeline for a single refresh:

And zoomed in even more to the portion of refresh that gets repeated:

The basic flow of the section that repeats is:

1. Blur/focusout events
2. Recalc style
3. Lots of separate parse HTML sections
4. Recalc style
5. Layout
6. Focus/focusin events
7. Recalc style
8. Layout

Looking at this, refresh's performance could still certainly be improved. In the meantime another thing that would be good to have to protect against this is to skip refreshes if a refresh is already in progress.