the thing to remember about terminal performance is that you can trade
off update rate with throughput to your heart’s content. That is, to
make a really fast terminal, never update the screen until the child
process stops outputting. To make a really slow terminal, update the
screen every time the child process outputs a single byte. To make a
reasonable terminal, pick some spot in the middle, or try to come up
with a fancy algorithm for when to repaint.
To compare the paint speed or parsing speed of two terminals you
probably have to somehow get those two terminals to follow the same
rules on updating, and you may also want to configure them
feature-equivalent in terms of font rendering and i18n.
Moral of the story is that when optimizing a terminal you can’t just
make it as fast as possible, you first have to define the
behavior/features you consider acceptable, and then stay “within spec”
as you optimize. Anyone can write a fast terminal if “cheating” is
allowed but it isn’t clear what constitutes “cheating.”
I’m not trying to say anything good or bad about VTE or the
performance patches for it, since I haven’t looked at those, just
making a general observation.
(This post was originally found at http://log.ometer.com/2005-02.html#23)