I wonder how much “deep” profiling we can do to improve things, e.g. to know how much is just graphics, how much is time spent processing byte-sequence spam, or

I wonder how much “deep” profiling we can do to improve things, e.g. to know how much is just graphics, how much is time spent processing byte-sequence spam, or heck even time spent processing scrollback buffers and stuff. I suspect it would turn out to be a mix. And I strongly suspect we could identify just a handful of efficient terminal sequences and push for broader support of the most efficient ones (i.e. things that directly tell the emulator to do X instead of receiving three dozen other sequences that produce the same result). Graphics are a likely culprit but even then there can be multiple layers to the problem, sometimes literally. Putting bits in a window can be surprisingly expensive and it’s hard to have nice bells and whistles and speed at the same time. It’s hard when given many bytes at a time. I once observed that simply by splitting a “vim” buffer vertically, my terminal received a significantly greater number of bytes (such as extra spaces for layout and several more special terminal sequences). The split also seemed to trigger more “full screen” or “most of screen” refreshes, versus smaller and cheaper updates that were typical of single editors. Scrolling, as it turns out, is a lot more complex in a split buffer.