Comprehensive Linux Terminal Performance Comparison
Linux has an abundance of excellent terminal applications. Interestingly, I could not find any decent comparison of their text display performance. Since I use the command line a lot, I want text output that is as fast as possible. When you compile a large project, you don’t want the console output to be the limiting factor.
System
Due to popular demand, here is what my test system looks like: Ubuntu 7.04, Gnome, ATI Radion Mobile 9600 with fglrx driver, and a Pentium M with 1.5 GHz.
The Benchmark
I took the burden on me to do a comprehensive comparison of the text through of all possible terminals. The benchmark is very simple, I timed displaying the whole content of RFC3261. Download the file if you want to make your own benchmarks. The benchmark is executed like this:
time cat rfc3261.txt
I have measured the time in seconds. Without further ado, I give you the results (click here for a better readable PDF version, or click the image for a larger view):

larger view
Runtime in seconds timed with time cat rfc3261.txt.
Results
These are some very interesting results:
- Both gnome-terminal and konsole are exceptionally fast, it takes only 0.25 to 0.59 seconds to display the 647976 bytes large file. They buy the speed with quite a bit of memory consumption, and it can be clearly seen that the output does not smoothly scroll but only updates several times per second. This is a clever trick and has the advantage of being extremely fast, because not every letter needs to be pumped through the X windowing system. If you compile a lot or have other automatically generated output, gnome-terminal and konsole are the clear winners.
- konsole uses a lot of memory, about 32 MB. When setting the history buffer to 10.000 lines, it increases to 38MB per instance.
- gnome-terminal has a very different memory behavior. When you open multiple terminals, they are all memory managed from one gnome-terminal instance. This one instance requires about 45 MB freshly started. When opening multiple terminals and each one with 10.000 lines of used buffer, each terminal requires about 16 MB, so when you open more than three terminals at once you have already lower memory requirements than when using konsole.
- xterm is the slowest terminal. While it is probably the most widely used term, the only slower terminal is Microsoft Window’s cmd.exe! Each instance requires 16 MB RAM, which is a lot in comparison to other terms with similar features.
- wterm is both reasonably fast and the most memory efficient of all tested terminals. Each instance requires only about 6.3 MB of RAM, even with 10.000 lines of buffer. Only aterm but without buffer comes with 6.5 MB pretty close.
- Eterm is quite fast and memory efficient (9 MB), even with transparency.
Conclusion
So, what is the best terminal? The answer is actually quite simple:
- If you want speed, use gnome-terminal or konsole.
- If you are low on memory, use wterm, rxvt, or Eterm.
- xterm is slow.
UPDATE: Of course, the answer is actually not so simple. As some have told me, they get a quite different performance behavior on their system. I suspect that both the linux scheduler and the X scheduler has a lot to say in this issue too. So if you want to have results you can trust, you have to redo the benchmark on your machine. Fortunately, that’s simple: just cat a large file and measure the time it takes. Be sure to run it multiple times to get more accurate average numbers.
Other Remarks
- Windows does not have the time command, so I wrote a simple Ruby script that does the same thing:
before = Time.now system(ARGV.join(" ")) after = Time.now puts "#{after-before} seconds"Also, cmd.exe only allows 9.999 lines of buffer.
- If you want to display bitmap fonts in gnome-terminal, edit ~/.fonts.conf and add these lines right after the <fontconfig> opening tag:
<!-- Accept bitmap fonts --> <selectfont> <acceptfont> <pattern> <patelt name="scalable"><bool>false</bool></patelt> </pattern> </acceptfont> </selectfont>
I hope this is helpful in your choice of the best console.
Tags: benchmark, comparison, linux, performance, terminal, ubuntu82 Comments
Trackbacks
- Free as in Free Beer » Blog Archive » Terminal Benchmark
- eastredsix.us/wp - RFC familiarity
- Marek Mahut » Linux Terminal Performance Comparison
- .bootstrap » Linux Terminal Speed Performance Comparison
- Command Line: Windows and Linux Terminal Performance Comparison · TechBlogger
- Windows and Linux Terminal Performance Comparison at SoftSaurus
- Solo encuentra el que sabe buscar……. casper255 » Blog Archive » En busca del terminal mas rapido
- Unatine :: blog : links for 2007-09-08
- Command Line: Windows and Linux Terminal Performance Comparison | Tolagomi News
- Aoortic » Command Line: Windows and Linux Terminal Performance Comparison
- Terminally Incoherent » Blog Archive » Installing Fluxbuntu on Compaq Presario 1240
- Blogaritmo natural » Comparación de terminales de Linux
- 랜덤여신의 폐인모드
- Windows and Linux Terminal Performance Comparison [Command Line] at SoftSaurus


September 2nd, 2007 at 4:15 pm
you should try “mrxvt” - you’ll be really surprised by performance and features!
Rgds,
-root
September 2nd, 2007 at 7:23 pm
Hi anonymous, thanks for the suggestion! I have tried mrxvt, and it is the fastest term. A bit faster than gnome-terminal, but I need a larger file to get more consistent numbers..
With 10k lines buffer it uses 9.5 MB RAM, which is quite good because it features tabs. An additional tab with the benchmark run once increases the memory usage to 14 MB.
September 3rd, 2007 at 11:52 am
mrxvt is fast, that’s true. But no UTF-8 support yet which is a big downside
September 5th, 2007 at 5:40 pm
Mac OS X - Teminal.app is very fast
cat rfc3261.txt 0.00s user 0.02s system 9% cpu 0.212 total
September 5th, 2007 at 6:07 pm
How many runs per terminal did you do?
It would also seem to be very system dependent. Running three trials with the same file you used, running on a 1.6GHz UltraSPARC IIIi, with four of the selected terminals, I got a near in inversion in performance. Below are the best times and worst times for each terminal:
dtterm: 0:00.79 - 0:00.86
xterm: 0:01.14 - 0:01.60
rxvt: 0:01.93 - 0:02.05
gterm: 0:10.91 - 0:14.48
So it may be best for any given user to test their preferred terms on their own system rather than take the benchmarks from any given system and assume it’s also good for theirs.
September 5th, 2007 at 6:08 pm
Notably the development version of Konsole, i.e. what will end up being in KDE 4, has seen significant speed optimizations by its new maintainer, Robert Knight (along with a redone and far nicer UI). So the already-splendid benchmarks are only going to get better.
September 5th, 2007 at 6:18 pm
Xiphos, that are interesting results. Which version of gnome-terminal did you use? Xterm consistently takes around 5.5, 5.7 seconds or so. Also, I suspect that the X and the linux scheduler has also a lot to say in this issue. I did not know the differences can be that huge, so you are right that everyone probably has to test this himself for his system.
PS: I have removed your duplicated comments on the other blog entry
September 5th, 2007 at 6:22 pm
Some questions for you now that I’ve done some thinking - what are you running along with X and the terminals? Gnome and KDE both have terminals that most likely “work” better with the respective environments. I know that for sure gnome-terminal starts faster when I’m running gnome, and konsole starts faster when I’m running KDE. Does xterm perform better in TWM or Fluxbox? or does Eterm perform better with E (16 or 17 ?!). I am curious about the various combinations.
And one more thing… why isn’t the standard console listed (i.e. no X at all)? I’d bet that blows away the competition hands down but I could be wrong…
September 5th, 2007 at 6:26 pm
I find this benchmark to be largely pointless, as it actually more tests how fast the terminal can send data to X and have it rendered. Here, for example, using urxvt in a urxvtd + urxvtc configuration, I get about 0.3 seconds catting that file using the NVIDIA driver on my system. Which is in contrast to your benchmark, which gets at best 1.5 seconds. Even more impressive, urxvtd consumes only 13MB of memory, with multiple terminals open (as it merely generates multiple windows from one process, rather than one process per window), making it at least on-par with gnome-terminal at significantly less memory usage.
If I were to benchmark this using say, the vesa driver or the nv driver in Xorg, I’d probably lose performance because of the lack of render acceleration in either driver (welll, full render acceleration for nv).
cat’ing a file is not a proper benchmark of the terminals scroll speed, it’s more a proper test of X’s rendering speed.
September 5th, 2007 at 6:30 pm
sequethin,
“And one more thing… why isn’t the standard console listed (i.e. no X at all)? I’d bet that blows away the competition hands down but I could be wrong…”
He did include it: notice the “80×25 Text Mode Console” entry. It’s just surprising because it _wasn’t_ the fastest.. it seems it’s in 6th place.
September 5th, 2007 at 6:36 pm
@Andrew, the reason it was not the fastest is that it has to pump every character through the display driver. gnome-terminal is smarter, it skips a lot of content because it notices that the characters would be flying by without a chance to read.
September 5th, 2007 at 6:43 pm
Tried your test on the apple terminal.app on a first gen macbook pro and getting 0.045 - 0.075 seconds real time. terminal.app might use the duel core tho. Also its only using 10mb for one instance and 1-2 more mbs for another. While the xterm in X11 on a macbook pro takes 0.814s real time cant see how much memory it uses tho since shows as X11 (30mb for all of X11 including xterm).
Very interesting test, would be nice if you could tell us what hardware you are using.
September 5th, 2007 at 6:45 pm
You should test “terminal” from XFCE. It uses the same engine as gnome-terminal, but has a slicker setup.
http://www.os-cillation.com/index.php?id=42&L=5
September 5th, 2007 at 6:50 pm
to andrew: thanks, I missed that.
so Martin - have you enough inspiration now to give us a more comprehensive comprehensive terminal performance comparison complete with hardware specs and other juicy details? I hope so!
September 5th, 2007 at 6:54 pm
… oh and I forgot to say thanks for the article! I’ll stop commenting so much now…
September 5th, 2007 at 6:59 pm
@Niklas
That’s because Terminal.app is a native OS X application and makes full use of OS X’s Cocoa and the text is rendered via Quartz. X11.app on the other hand has a much greater overhead since it’s not native and doesn’t benefit from Quartz’s text rendering. Not only that, it has the network overhead to contend with too. No surprise then that it cannot compare to Terminal.app.
September 5th, 2007 at 7:35 pm
Just for fun, I did this test on an ssh session using putty (under windows vista) to my Linux box:
real 0m0.631s
user 0m0.000s
sys 0m0.017s
Which is about 0.1s slower than running the test locally in aterm. Running the aterm over ssh on windows (via Cygwin/X and putty) is about 2 seconds more.
September 5th, 2007 at 7:51 pm
I did my own test (on Pentium M 1.6, Intel 915, EXA acceleration) to check how big performance gain will KDE4 bring.
Konsole from kde 3.5.7:
real 0m2.159s
user 0m0.004s
sys 0m0.024s
Konsole from KDE4 (svn build from several days ago):
real 0m1.299s
user 0m0.000s
sys 0m0.012s
September 5th, 2007 at 8:18 pm
urxvt: cat rfc3261.txt 0,00s user 0,02s system 41% cpu 0,055 total
September 5th, 2007 at 8:36 pm
These tests are all hogwash. He was pulling from a file, the problem with this is that terminals can be smart and do some reading and pre-allocate buffers. A better test would be to read from a named pipe while cat”ing the RFC into the pipe. This has the feature that it tests piped/generated output which is much more common than a simple cat to stdout.
September 5th, 2007 at 9:39 pm
on my system, urxvt in client-daemon mode
daemon=urxvtd -q -o -f
client=urxvtc -j -ss -sb 10000 -fn xft:Terminus:pixelsize=14
(jump scrolling,skip scrolling, 10000 lines scrollback, Terminus font) running fullscreen (COLS=237, LINES=83) finishes this test in:
real 0m0.126s
user 0m0.010s
sys 0m0.050s
Mabye a bit of time tweaking your terminal settings is in order.
September 5th, 2007 at 10:57 pm
The chart shows rxvt slower - though it’s not easy to tell since the given data mixes features, and has few side-by-side comparisons.
You might try using the same scale for each of the rows - it would help you to understand your raw data.
September 6th, 2007 at 12:42 am
Terminal.app on C2D 2.2GHz macbook pro with 8600m GT gfx in OS X 10.4.10 (with safari, last.fm running.)
real 0m0.029s
user 0m0.001s
sys 0m0.015s
real 0m0.050s
user 0m0.001s
sys 0m0.016s
real 0m0.024s
user 0m0.001s
sys 0m0.015s
real 0m0.024s
user 0m0.001s
sys 0m0.015s
real 0m0.026s
user 0m0.001s
sys 0m0.014s
September 6th, 2007 at 1:00 am
@Ray (21): I’ve never heard of a terminal app predicting the output like that, can you point one out? And how does a pipe test the speed of rendering text in a terminal emulator better than any other source of text?
September 6th, 2007 at 2:37 am
I saw Terminal and Tilda were left out. And although they both use VTE like gnome-terminal I thought I’d try them. On my system Terminal too 1.135s while Tilda took 0.082s.
I actually run the project, so thought this was pretty cool. Anyone else get similar results?
September 6th, 2007 at 2:40 am
Terminal speed. And here I was thinking VT320s v. Wyse 60s. Kids these days.
September 6th, 2007 at 3:45 am
If you do this in a screen session, it IS the fastest. Here is my method and result:
1. open a screen session
2. time for ((x=0; x
September 6th, 2007 at 5:44 am
You have skipped xfce4-terminal which is another faster ( than gnome-terminal ) and light beast .
With terminus console fonts the speeds should be even better.
September 6th, 2007 at 6:15 am
You forgot mlterm.
September 6th, 2007 at 7:54 am
Performance of minimized terminal apps would be interesting as well. Would be more realistic ’cause you would minimize a terminal compiling some large kde stuff.
btw. compiling remotely via ssh I usually use screen so “screen” performance (backgrounded) would be interesting too.
September 6th, 2007 at 8:45 am
Sorry, but your memory numbers are way off. Konsole instances don’t use 38MB each, not even close. Forget this useless top tool nobody can use properly anyway, learn how to use exmap (http://ktown.kde.org/~seli/memory/).
September 6th, 2007 at 9:12 am
You forgot the VGA console on x86. And something like 800×600 framebuffer (on x86 preferably, also sparc if possible).
>These tests are all hogwash. He was pulling from a file, the
>problem with this is that terminals can be smart and do
>some reading and pre-allocate buffers.
Can you prove it? A terminal is a terminal and intercepting the keystrokes to see whether the user does ‘cat’ or whatnot seems like the terminal app should be placed on DoingItWrong.com. The test is to determine the amount of characters displayed per time quantum for a given blahterm. If you want, you can do away with the file and synthesize data by other means.
September 6th, 2007 at 10:19 am
$ du rfc3261.txt
640 rfc3261.txt
$ time cat rfc3261.txt
gnome-terminal:
real 0m0.043s
user 0m0.000s
sys 0m0.009s
xterm:
real 0m0.401s
user 0m0.000s
sys 0m0.009s
terminal (xfce):
real 0m0.056s
user 0m0.000s
sys 0m0.011s
rxvt:
real 0m0.078s
user 0m0.000s
sys 0m0.015s
Note: using compiz-fusion
September 6th, 2007 at 12:18 pm
you didn’t measure 9term and acme from plan9.
9term (with scroll on, it is not measurable with scroll off) makes a discrete 0m3.243s, but executing the command from acme gives an incredible time of 0:00.79, arriving to the sixth position in the rank (the seventh if you add mrxvt). Not bad if we take in count it is not just a terminal but a complete text editor, window system and ide with a memory footprint of less than 2mb with several open files. Just FYI.
September 6th, 2007 at 2:34 pm
Saying that cmd.exe is the slowest is good, but where is the facts?
September 6th, 2007 at 2:53 pm
What’s the point? We don’t read the output anyway. Why not
$ time sh -c “cat rfc3261.txt >/dev/null”?
:p
September 6th, 2007 at 4:05 pm
> Results
No comments about urxvt?
Also urxvt has problem displaying properly some fonts comparing to xterm for example: http://vermaden.proplayer.pl/gfx/screenshots/vermaden-xterm-urxvt.png
… with same settings for both terminals of course.
Overall, nice comparasion.
September 6th, 2007 at 6:41 pm
What about Terminal (also know as XFCE Terminal) ?
September 6th, 2007 at 6:55 pm
XFCE is exactly the same as gnome-terminal, as far as I know both use the same base sourcecode.
September 6th, 2007 at 7:04 pm
gnome-terminal achieves such level of performance just beacuse performs much of the updates in a buffer and refreshes from time to time (rarely - and very annoying in some circumstances).
It basically does the equivalent of framedropping, and that’s really no performance at all.With framedropping and refresh every once a second anybody can achieve impressive results at your test, however the overall impression and slow refresh make the app feel very sluggish.
Konsole also does buffering, but it’s not so easy to visualise that (it seems to refresh often and you can see the screen scrolling, not just see the whole area redrawed with a completely new content ).
September 6th, 2007 at 8:50 pm
I think this benchmark does not make much sense. A text in
terminal is kind of intended for a human to read. If a program
produces so much output that terminal speed becomes an issue,
it is better to send it to file or /dev/null anyway.
I like about xterm that it supports UTF8 and eight-bit input,
i.e., Alt-i produces an eight bit sequence instead of i
characters such as in gnome-terminal or konsole. If anybody knows of other graphical terminal that support eight bit IO,
please let me know.
September 7th, 2007 at 9:10 am
Anonymous (#10) wrote:
> I find this benchmark to be largely pointless, as it
> actually more tests how fast the terminal can
> send data to X and have it rendered.
The point of a benchmark is to perform a *comparative* analysis given a particular environment. It’s obvious that speed is the issue here and arises from the fact that some shells are doing their job faster than the others.
> If I were to benchmark this using say, the vesa
> driver or the nv driver in Xorg, I’d probably lose
> performance because of the lack of render
> acceleration in either driver (welll, full render
> acceleration for nv).
You’re stating the obvious but anyway you’d be comparing nv vs nvidia… As interesting as it may be to try these benchmarks on both drivers, the point here is to find out whether some terminals perform better or worse relative to others.
September 7th, 2007 at 3:22 pm
try urxvtd+urxvtc
September 7th, 2007 at 3:57 pm
where is urxvtd+urxvtc?
September 7th, 2007 at 4:15 pm
What about wine console? (user backend only)
September 7th, 2007 at 7:30 pm
I’m backing up sequethin here.
.022 ms on Mac OS 10.4.10
September 7th, 2007 at 7:43 pm
thanx for an interesting article.
btw., there is ‘ntimer.exe’ in the windows resource kit tools pack
September 7th, 2007 at 8:05 pm
Wow, I understand the test but why would you even post a result that was done from a remote host over an ADSL connection and consider that to be accurate? Putty running locally like the others would have probably been more fair to it.
September 7th, 2007 at 8:31 pm
I’m with #54. Loading the file through PuTTY over a network compared to loading files locally via other terminals isn’t what I would call an apples-to-apples comparison.
September 7th, 2007 at 9:41 pm
This benchmark is seriously botched!
Urxvt (full unicode, multiple character sets in one window at once) does it in 0.043, taking 2.8 MB at start. Mem is growing with the scrollback as it gets filled. It is obviously the winner here!!
Next time you test, use default config - no TTF, no antialias. It still has cleaner font than any TTF and can display more character sets than the rest of term together.
My results (same doc, same cmd):
urxvt 0.041s
rxvt 0.043s
gnome-term 0.188s
konsole 0.630s
xterm 0.679s
RAM (RSS):
urxvt 2.8 MB
rxvt 2.9 MB
xterm 4.2 MB
gnome-term 15.6 MB
konsole 18.4 MB
September 7th, 2007 at 9:44 pm
This comparsion is somewhat flawed:
1. Text terminals are *not* used to display very large chunks of text - it is pointless. It does not matter if my terminal displays 3MB of text in 10 seconds or 4 minutes since if I wish to read this text it would take me about few hours. So your test is an absurd one. If I’ve wished to read some text I would use less (or better - most). If I’ve wished to grep some large chunks of text - well I would grep them. Main use of text terminal is *not* to display very large chunks of text. My test would rather consider:
- how fast it launches
- how fast it scrolls between pages
- how fast it renders text (this is the test which you did - but in fact you tested more low level library that renders the text)
2. You did not test all of terminals - probalby the fastest will be the ones that use OpenGL.
September 7th, 2007 at 10:49 pm
+1 good test!
We don’t always want to read *everything* in our windows… if I’ve got a huge tarball I want to undo, and I want to monitor its progress, I might be tempted to use -v.
If this tarball contains tons of tiny files, I don’t want the operation to take 5 times as long because the terminal can’t display fast enough.
A real fast terminal would let me glance at the text flying by and have a good idea how well the untarring is coming.
September 8th, 2007 at 4:06 am
now here’s the real test of terminals…
$ time for i in `seq 1 100`; do xterm -e false; done
real 0m5.389s
user 0m1.044s
sys 0m0.396s
$ time for i in `seq 1 100`; do gnome-terminal -e false; done
real 0m41.062s
user 0m30.482s
sys 0m2.720s
September 8th, 2007 at 4:40 am
I think the reason you thought konsole is a memory hog is because you ran it from Gnome and so it had to load kdelibs and stuff. If you run it from KDE then konsole and gnome-terminal should be quite close.
September 8th, 2007 at 6:02 pm
#60 - not true if he measured RSS, which I presume he did
it would be the same if ran from KDE of GNOME
September 8th, 2007 at 6:33 pm
IT’S NOT FAIR AT ALL - for Konsole you allow “skip” mode, which doesn’t really display all the contents, but for e.g. rxvt you don’t…
If you run rxvt (or urxvt) with -ss -j, then it will outperform ALL competitors by two orders of magnitude! It’s finished in about 0.030s (real).
1) If somebody wants to see all the lines, one by one - he doesn’t care for speed, really (this is the least usual approach).
2) If he wants super fast scrolling, but also needs to be able to scroll back (e.g. for compile errors), he will use skip mode (the most usual approach)
3) If he ignores output, he will suppress it or send to /dev/null
By these measures, rxvt would be the all round winner here.
It allows all three modes and with optimizations you allowed for others (skip mode - for me permanent default) it is THE FASTEST term out there.
Not mentioning usability, which is the real point here. Rxvt can display whole Unicode set, in round the globe “character sets” at once. I don’t think others can cat a document with native thai, russian and arab texts and be readable:
http://img405.imageshack.us/img405/5326/setsgd2.jpg
As one of its devels, I’d like to ask you to include rxvt in the graph. It took a lot of effort to bring it where it is now…
Thanks, really.
September 9th, 2007 at 2:29 am
Hi,
Thanks for doing that test. I think we could tweak it a bit to get more accurate results, but it still is interesting.
I see a glaring problem in some of the results toward the bottom. I can’t imagine how it took _nine_ seconds to display rfc3261 in a cmd window! I’m running XP and I’m getting it delivered in full before I can get my finger off the [enter] button! Something’s terribly wrong there. I didn’t see that you are running a loop. Are you running a loop?
That file isn’t that big. I’d be interested to know if you’re running cmd.exe under wine, or in VMWare or something like that.
September 9th, 2007 at 9:28 am
man, what cracking perform from gnome-terminal! and what a slug is the old xterm. Results from a pentium M 1.6 Dell latitude graphics that uses intel graphics and shared mem running Ubuntu 7.04. and yes mrxvt is the winner! I never would have guessed!
real 0m0.152s
user 0m0.000s
sys 0m0.044s
gnome-terminal, a very close second
real 0m0.274s
user 0m0.000s
sys 0m0.028s
wterm, an old fav:
real 0m1.124s
user 0m0.004s
sys 0m0.008
eterm, the glamor term:
real 0m1.290s
user 0m0.004s
sys 0m0.028s
and xterm the slug, the only thing good about it is it’s fast loading:
real 0m1.727s
user 0m0.008s
sys 0m0.032s
out with the slackers!
September 9th, 2007 at 8:24 pm
good work, but in terminal, there is another time element - scrolling, try this in your terminal:
dmesg
end then scroll (via mouse is the best), you can view very interesting values about your cpu load …:(
September 18th, 2007 at 11:26 pm
there is a noticeable difference if you are outputting text to the console (real text-mode console) but looking at a different vt. that’s what i do, i haven’t timed it though.
December 4th, 2007 at 12:38 am
I think Martin’s pretty lucky here that he’s achieved nearly 50% of commenters with a brain - often it’s a lot lower than that. But some of these people are really getting themselves all heated up for very little reason; Martin did not claim to be conducting the final, ultimate test for all Linux terminals, and he is not preventing you from providing your own tests. How many of you provided such information of your own on your own blogs?
This is a useful guide, not the only one, to terminal speed. By all means, conduct your own tests and offer opinions and advice, but don’t hassle him for not thinking of everything. Really, some of you are such babies - that’s why I banned commenting on my blog.
Thanks to Martin for providing a useful reference and a great guide for debating and ruminating over, and thanks to the nearly 50% who had something useful and intelligent to add!
December 5th, 2007 at 11:08 pm
This is just silly. I ran it in gnome-terminal, and I got 2 (two) screen updates. No wonder it’s “fast”. In XTerm, no text is left out from the output, a feature which should not be taken lightly. The eye is extremely good at spotting unusual patterns, and when compiling software, this means you can quickly notice when something is amiss. Of course, I agree with others that you really need to use tee(1) and less(1) afterwards to really study the output.
In any case, for my usage, gnome-terminal is completely useless. Konsole is a little better, it does perhaps a dozen screen updates, but it still is no match for the *much* faster rendering of XTerm (rxvt is probably just as good as XTerm, if you don’t need the Tektronix emulation
December 9th, 2007 at 1:41 pm
i’ve been using xterm for a LONG time, maybe 7 years or so.
i like it because its compact and simple, i’ve never had the time to fiddle another flashier terminal to be as “clean”.
i’ve been aware of xterms performance limitations for a long time now, the reason for them in my case is this :
xterm -T rwdlsd -sb -sl 100000 -ls -bg grey80 -fg black
100,000 lines of buffer.
it eats a LOT of memory per instance when maximised. 208MB per instance, or 91MB per 80×25 instance.
it took 1:20 for your test on my 1800 turion 64 at max speed with that desktop displayed.
maximised it took 1:23
i opened gnome-terminal and set the buffer to 100,000 lines and it took :
real 0m1.973s
user 0m0.000s
sys 0m0.028s
to do the same job. hopefully i can tune it to be plain and boring too.
if you have any hints on duplicating the behaviour i’m used to, i’m keen to hear them.
thanks for your write up
December 12th, 2007 at 2:00 am
There was a really good explanation of why all this is wrong here, but your blog decided to swallow it.
I’m annoyed, I’m not going to write it again. Basically, your results are incorrect as you’re timing how long it takes “cat” to terminate, NOT how long it takes to display anything on screen.
I can trivially write a terminal that reads everything from cat as quickly as possible, which would pass your test above with flying colours, yet still not render a single character to screen.
This is probably what gnome-terminal does to get its speed increase over the other terminal emulators. As you can see from the anecdotal evidence above, it doesn’t display to the screen as often as a real terminal emulator, and certainly wouldn’t display the same speed increases if faced with a large number of very small writes or changes, such as is caused by your common or garden console application.
Please *please* flag these misleading statements about xterm and gnome terminal as such. These results are not useful for anyone picking a terminal, and just lead to the pollution of the small amount of useful information on the Internet about this subject, which is how I ended up at this page in the first place. A member of an IRC channel quoted these results as the reason that “gnome-terminal is faster than xterm”. Having anecdotal evidence to the contrary (and timings of real-world applications, such as a large compilation, taking about 5s faster on xterm than gnome-terminal over a 2 minute compilation) I decided to look into this and find out why it was incorrect.
I STRONGLY urge any reader of this page to actually test each of the popular terminals themselves, with the applications and use cases that they are going to use them for.
December 18th, 2007 at 9:58 am
Michael has a point, but there is one thing the test is good for is for: determining which terminals will slow down commands with lots of low-information-value output, such as the debug options to some commands. The Linux console benefits from hardware designed to display monospace text but lacks jumpscroll, and because of that it can actually slow down a program considerably if there’s a lot of output. I was surprised.
December 22nd, 2007 at 8:41 pm
hi Michael, I am sorry if your previous post was somehow swallowed. I only delete spam messages with links to dubious sites, never other opinions.
In my experience gnome-terminal *is* faster than xterm, because it is smarter. no terminal has any idea which program is used, so instead of cat you can also use any other program that quickly pumps out characters to the screen.
December 26th, 2007 at 5:50 pm
Hi,
IMHO the results for Windows look suspicious. I never have anything even close to that on any Windows machine. I used fixed raster font for cmd and interrupted “cat rfc3261.txt” in a minute. The same results for “type rfc3261.txt”. The Cygwin’s rxvt does “cat rfc3261.txt” in about 1 sec even with larger font. How did you manage to get the same time for xterm and cmd ?
December 27th, 2007 at 3:08 am
I did some comparations for rxvt, xterm ( Linux ) and windows console ( 2000 Pro, cmd.exe ) with similar enviroment: almost the same accelerated nvidia drivers; window size: 91×35; fonts: xos4-terminus-bold 20px ( linux ) and “Raster Font” 10×20px ( windows console ).
Windows console has screen buffer size == window size. rxvt and xterm have default buffer size.
The Results:
rxvt: 0.8 sec
xterm: 2.8 sec
windows console ( cmd.exe ): 23.6 sec