Linked by Thom Holwerda on Wed 5th Sep 2007 17:18 UTC, submitted by SEJeff
Benchmarks "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. I took the burden on me to do a comprehensive comparison of the text through of all possible terminals."
Order by: Score:
Guess those speed improvements paid off
by pllb on Wed 5th Sep 2007 17:40 UTC
pllb
Member since:
2007-04-30

Looks like the gnome devs did a good job on the speed front when they worked on gnome terminal...I'm surprised at xterm though, it always felt fastest to me.

Reply Score: 1

SEJeff Member since:
2005-11-05

Believe it or not, it isn't gnome-terminal that is fast, but vte. Behdad Esfahbod is on the gnome performance team and optimized the holy crap out of vte. Vte is the underlying library that displays the actual terminal in gnome-terminal.

http://ftp.acc.umu.se/pub/GNOME/sources/vte/

Reply Score: 7

More information would be useful ...
by Robert Escue on Wed 5th Sep 2007 17:43 UTC
Robert Escue
Member since:
2005-07-08

Like what kind of system the test was conducted on and the quality of the network connection.

Reply Score: 2

sequethin Member since:
2005-07-06

I agree - also what is he running along with X? 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...

Reply Score: 2

evangs Member since:
2005-07-07

Why would that be the case? These terminals that aren't native to KDE/GNOME are not going to be using any of the respective toolkits. So I fail to see how that would affect performance. I don't know if there is any extra layer when communicating with the X server.

Perhaps someone else could shed some light?

Reply Score: 2

martinus Member since:
2005-07-06

Hi, I'm the author of the comparison. I have also done a test of the normal console without X, but have not written anything in the text. You can find it in the 6th entry of the chart, it was slower than gnome-terminal and konsole.

Reply Score: 6

scott.tiger Member since:
2007-04-08

I did a test on FreeBSD:
gnome-terminal: 0.150 - 0.180
ttyv (VESA 1280x1024): 0.013 - 0.040

~4 to ~14 times faster

EDIT:
ttyv (80x25): 0.021 - 0.024

Edited 2007-09-05 19:03

Reply Score: 4

antik Member since:
2006-05-19

I did a test on FreeBSD:
gnome-terminal: 0.150 - 0.180
ttyv (VESA 1280x1024): 0.013 - 0.040

~4 to ~14 times faster


It depends what "time" you are using:

I did test with external time application under 100% CPU load BTW (Installing Windows XP in Win4BSD).
# /usr/bin/time cat rfc3261.txt
2.16 real 0.00 user 0.01 sys

# time cat rfc3261.txt
0.002u 0.012s 0:02.45 0.4% 48+1696k 0+0io 0pf+0w
Not sure what all those numbers mean...

FreeBSD 6.2-STABLE #46: Tue Jul 10 13:00:41 PDT 2007
KDE 3.5.7, Konsole 1.6.6

Reply Score: 2

ssam Member since:
2006-03-12

when you start an applications it needs to read various libraries. if these have been read recently then they will be cached into ram.

gnome-terminal will need things like the gtk libraries. if you have already stared nautilus and gnome-panel, then the gtk libraries will be cached.

same for konsole and the qt/kdelibs

Reply Score: 2

evangs Member since:
2005-07-07

This article is measuring the performance of the terminal. The loading of libraries at startup should not affect the outcome as startup time is not measured.

Reply Score: 2

Ford Prefect Member since:
2006-01-16

The faster startup has one particular reason. It's not that the applications are faster within a specific desktop environment.

On startup, heavy apps like konsole or gnome-terminal need several shared libraries to be found and loaded into RAM. But they share most of these libs with other KDE/gnome programs.

You can try this out yourself:
- run ldd /usr/bin/gnome-terminal
- run ldd /usr/bin/gnome-panel
- compare ;)

Here, gnome-terminal needs 75 libraries to be loaded dynamically. gnome-panel needs 72. A diff shows that the two programs share 70 libraries! So if you already have the gnome-panel running, that's the simple reason why gnome-terminal starts up fast.

Compared to that, xterm only uses 22 shared libraries here. These are mainly X libraries. So if any other X app is already is running, chances are good xterm starts fast.

Reply Score: 3

martinus Member since:
2005-07-06

Hi, original author here: I have updated the site and added this information: I used Ubuntu 7.04, Gnome, ATI with fglrx, and a Pentium M.

Reply Score: 2

dopp0 Member since:
2007-08-29

Sure!!! If he had tested with a gigabit network card installed, the results would change this much!!! O_o

Reply Score: 1

Funny...
by whartung on Wed 5th Sep 2007 17:45 UTC
whartung
Member since:
2005-07-06

I read the summary and when he says terminal applications and I think applications like pine or vi. Applications that run within the terminal. Then I'm thinking "What could he be timing? Is pine faster than vi? How do you know? Timing ncurses performance? What kind of benchmark is this?"

Then, I pull my head out and "get it".

Reply Score: 2

konsole memory consumption
by slougi on Wed 5th Sep 2007 18:01 UTC
slougi
Member since:
2006-08-16

The konsole memory consumption mentioned in the article (32 MB) seems very high. I just looked at how much my instance with 3 tabs uses, top reports 16m resident and 12m shared. When I open a new one with just a single tab 15m resident is reported along with the 12m shared. Still a lot for a terminal, but a lot less than the article implies.

Edit: That's with a 1000 line buffer.

This was measured on Kubuntu Edgy with distro-provided KDE 3.5.7.

I remember a few years ago some similar testing was done, gnome-terminal was by far the slowest. I believe this was around the time of gnome 2.0, some nice improvements there apparently.

Edited 2007-09-05 18:05

Reply Score: 2

RE: konsole memory consumption
by evangs on Wed 5th Sep 2007 18:16 UTC in reply to "konsole memory consumption"
evangs Member since:
2005-07-07

Indeed, I'm very pleasantly surprised by how well gnome-terminal performs. I remember back in 2003 or so when people were recommended not to compile large projects in gnome-terminal because it was so slow that it would actually slow things down. This was back when I was using Gentoo, so I did a lot of compiling and any speed up was welcome ;)

Reply Score: 2

RE: konsole memory consumption
by segedunum on Wed 5th Sep 2007 19:34 UTC in reply to "konsole memory consumption"
segedunum Member since:
2005-07-06

The konsole memory consumption mentioned in the article (32 MB) seems very high. I just looked at how much my instance with 3 tabs uses, top reports 16m resident and 12m shared.

Of course it seems high:

1. They're using top (or I assume they are - they don't say). Not the way to try and measure actual memory usage, because Linux lies a lot about actual memory usage.

2. KDE apps use an awful lot of shared libraries that tend to get included in silly ad-hoc memory analyses like this.

Reply Score: 2

RE: konsole memory consumption
by looncraz on Thu 6th Sep 2007 17:20 UTC in reply to "konsole memory consumption"
looncraz Member since:
2005-07-24

BeOS's Terminal is taking about 1.3 MB on my machine right now, and it has a filled text buffer after compiling Haiku and now running an oft-interrupted bit-torrent download.

My 768MB goes VERY far on BeOS, that is, until I use Firefox, which uses 42MB on its own, and causes the system to reserve about 30MB more, and that is not counting any server's allocations needed to support the application while running ( does include all libs, though ).

Still, Firefox on Ubuntu sucks up the RAM even worse on this machine, I often run out of memory ( and SYSTEM responsiveness ) when playing only one or two flash movies, or just trying to do a lot of browsing, but then Firefox is normally only using 250MB or so, it is the rest of Ubuntu that is sucking up the RAM, each little daemon and background application needed to provide functionality on Ubuntu uses an abysmal 2MB or so, when there is likely no need for that amount of usage for the feature set.

Is this just how the GNU/Linux kernel as compiled and patched by Ubuntu allocates? I think I will be compiling me a new kernel today :-)

--The loon

What?... I was mostly on-topic.

Reply Score: 2

wrong test
by pmarin on Wed 5th Sep 2007 19:28 UTC
pmarin
Member since:
2006-12-30

I believe that this test is stupid. gnome terminal is the fastest because it eat text when it make the scrool. try to scrool in vi with gnome terminal, it is the most ugly terminal. The test is only useful for terminals when you are compiling no in the every day use.

Reply Score: 2

RE: wrong test
by SlackerJack on Wed 5th Sep 2007 19:37 UTC in reply to "wrong test"
SlackerJack Member since:
2005-11-12

Compiling is what most distro devs do, programmers do, source based distros do, package builders do, I call that eveyday use.

Reply Score: 5

RE[2]: wrong test
by pmarin on Wed 5th Sep 2007 19:51 UTC in reply to "RE: wrong test"
pmarin Member since:
2006-12-30

Most of the time I spend in my Unix is in a xterm and the scroll while you are compiling is'n so often because normally you compile the code that you are changed. I spend most time coding in Vim than compiling (the last *always* run in background). Perhaps you don't use the terminal in the interactive mode.

Reply Score: 1

RE[2]: wrong test
by MrSidecar on Thu 6th Sep 2007 11:21 UTC in reply to "RE: wrong test"
MrSidecar Member since:
2007-02-13

I have another question: Does the text output speed really affect compiling speed that much? I mean, If youŽd want to know hof fast gcc works in a respective terminal app, why not, uh, time THAT and compare those results? WouldnŽt that be more informative on this matter?

Reply Score: 2

RE[3]: wrong test
by Soulbender on Thu 6th Sep 2007 12:17 UTC in reply to "RE[2]: wrong test"
Soulbender Member since:
2005-08-18

"Does the text output speed really affect compiling speed that much?"

No. It's pretty unlikely that text output speed would be a major limiting factor for the time it takes to compile something.

Reply Score: 2

RE[3]: wrong test
by polyex on Fri 7th Sep 2007 05:21 UTC in reply to "RE[2]: wrong test"
polyex Member since:
2007-07-11

Your on the money in your observation. It means nothing, thats why this is article is just beyond stupid. Worrying about how fast your terminal is gets you out of actual coding, which is probably the root of this guys problem.

Reply Score: 1

RE: wrong test
by shapeshifter on Wed 5th Sep 2007 21:25 UTC in reply to "wrong test"
shapeshifter Member since:
2006-09-19

I believe that this test is stupid. gnome terminal is the fastest because it eat text when it make the scroll. try to scroll in vi with gnome terminal, it is the most ugly terminal. The test is only useful for terminals when you are compiling no in the every day use.


Well, I wouldn't call the test stupid, but it's certainly not very accurate.
The fact is that Gnome terminal is not really running the test as intended because it's skipping a lot of the text.
Try to scroll a large text file and you'll see that it's quite slow.
Konsole is quite fast as is Xterm, about as fast, it will scroll smoothly larger volumes of text.
Maybe it's just the difference between our systems?

Reply Score: 2

thanks all
by sequethin on Wed 5th Sep 2007 19:41 UTC
sequethin
Member since:
2005-07-06

I ended up learning a bit about things by asking questions here and @ the blog where the article is posted so thanks to all (and to martin of course for the article).

Reply Score: 2

Results from OS X
by CrimsonScythe on Wed 5th Sep 2007 20:09 UTC
CrimsonScythe
Member since:
2005-07-10

I just ran the test on my MacBook Pro, and it seems that Terminal.app is quite fast, and iTerm.app is fairly decent. Here are the results:

Terminal.app with 10,000 lines buffer: 0.02s
iTerm.app with 10,000 lines buffer: 0.34s

Reply Score: 3

urxvt
by acobar on Wed 5th Sep 2007 21:35 UTC
acobar
Member since:
2005-11-15

Well, I compile a lot of code and always use or xterm or urxvt. I'm not sure if this test is good enough. Perhaps someone can answer these questions: do gnome-term and konsole use lots of cpu time to render text fast, "skip" tricks and scroll optimizations on X? If so, what is the impact on CPU usage? What about the memory consumed and possible paging increase?

If someone really wants to find the best console to use on projects "configure/make" steps I suggest to pick a huge project to be build, like KDE, and then compare the results.

And one last thing, PLEASE developers of autoconf, automake and libtool, CACHE the result of queries. It for sure will SPEED-UP more than anything else the building time.

Reply Score: 2

RE: urxvt
by Doc Pain on Wed 5th Sep 2007 23:42 UTC in reply to "urxvt"
Doc Pain Member since:
2006-10-08

"If someone really wants to find the best console to use on projects "configure/make" steps I suggest to pick a huge project to be build, like KDE, and then compare the results."

It would be interesting on a scientific / statistic basis (more testing values - better proven results), but the use of a specific terminal won't speed up compiling. If I remember correctly, an older urban legend claimed compiling processes finishing earlier if any output is redirected into /dev/null. I think buffering is what makes the compiling process speed not being limited by the terminal output speed.

Now kidding: The mentioned terminal applications are terminal emulators. Terminal emultors are for children. Real men use real terminals. Real terminals are hardware. Hardware for hard working men. I've still got around a DEC vt100 and an EAW P8000 KSR around. :-)

Performance here is: 0.007u 0.023s 0:00.68 2.9% 16+312k 0+0io 0pf+0w (2 GHz Intel Celeron, Ati Radeon 9600, Driver ati + drm, FreeBSD 5.3/p5, XFree86 4.3.99.15, WindowMaker, XTerm)

Reply Score: 4

xfce4-terminal
by Savior on Wed 5th Sep 2007 22:09 UTC
Savior
Member since:
2006-09-02

Why is xfce4-terminal missing? On my system, it needs only about 60% of the time konsole takes to display the file. Is it that similar to gnome-terminal in the inside that it does not worth listing separately?

Reply Score: 2

RE: xfce4-terminal
by Ford Prefect on Wed 5th Sep 2007 22:46 UTC in reply to "xfce4-terminal"
Ford Prefect Member since:
2006-01-16

xfce4-terminal is a nifty program, but it uses the same widget for rendering gnome-terminal uses:

http://developer.gnome.org/arch/gnome/widgets/vte.html

Reply Score: 2

BeOS
by izomiac on Thu 6th Sep 2007 00:36 UTC
izomiac
Member since:
2006-07-26

Just for fun I did the test with the stock BeOS terminal. It didn't do too badly, ranging from 1.08 - 1.25 seconds. It does smoothly scroll through all the text though.

Reply Score: 2

stupid question
by richmassena on Thu 6th Sep 2007 03:31 UTC
richmassena
Member since:
2006-11-26

So the I/O to the screen is blocking? Sorry, I didn't RTFA so maybe that's answered within, but let me ask this.

If you redirect the output to a file and then do tail -f in another process, would the job run faster?

Maybe I'm not understanding this at all. I've always had the feeling that console I/O speed would slow down a process, but shouldn't the output to screen be decoupled (through non-blocking I/O, multithreading, something) so that until user input is required, the process would run unabated?

As a graphical example, if I'm copying a file in KDE, and grab the containing window, or for a better example, cause some kind of event in the window, the transfer doesn't pause while I do this. The window would go away readily enough when the transfer completed "underneath" my mouse.

Is this event-driven approach not appropriate to the console where programs can redirect I/O. Does this get into the world of message passing and mutexes and such that was eschewed in the early days of Unix, or am I just totally off the mark?

Reply Score: 1

Console output limiting?
by renox on Thu 6th Sep 2007 05:30 UTC
renox
Member since:
2005-07-06

Why doesn't he send the output to a file and tail the file, if the output is so huge that it use too much memory?

Edited 2007-09-06 05:32

Reply Score: 2

RE: Console output limiting?
by evangs on Thu 6th Sep 2007 10:37 UTC in reply to "Console output limiting?"
evangs Member since:
2005-07-07

Then you'd be measuring the performance of cat and not the performance of the terminal.

Reply Score: 2

RE[2]: Console output limiting?
by renox on Thu 6th Sep 2007 14:58 UTC in reply to "RE: Console output limiting?"
renox Member since:
2005-07-06

No what I was asking is why does he need a fast terminal?

Terminal scroll already faster than you can read it, so what's the point of having the fastest terminal?

If he just want to have the status of the compilation very fast, no need to 'display the output':
gcc foo.c >logfile 2>&1 ; echo "$?" is enough.

Reply Score: 2

signals
Member since:
2005-07-08

Strange this should be published now. I was just conducting similar tests trying to find the best terminal last weekend.

In my experience, he's right; gnome-terminal is FAST, unless you have xcompmgr or compiz running. Then it gets very slow and uses up massive amounts of CPU time (X eats up to 100% of one of my CPUs.) But, if I run rxvt, or one of it's descendants, with the compositing window manager on, it's much faster than gnome-terminal.

As soon as I kill the compositor, the performance flips, and gnome-terminal is the winner.

Does anybody have a guess as to why? Only gnome-terminal gives me problems with the compositor, Xterm, rxvt, etc. don't seem to be affected.

Reply Score: 1

Konsole
by robertknight on Thu 6th Sep 2007 14:26 UTC
robertknight
Member since:
2007-01-28

I am the current maintainer of Konsole (for KDE 4).

The file used in the benchmark is not large enough to get really useful feedback. There can be quite a lot of variation between test runs. My testing found that gnome-terminal/2.18 is an order of magnitude faster at catting very large files than Konsole/KDE 3 and about twice as fast as the current Konsole/KDE 4 build. The really, really expensive part is the text rendering and both "cheat" (compared to xterm) by cutting down the amount they do as much as possible. I'm not sure how he is measuring memory usage, but I make it 9MB of writable physical memory used on the test mentioned (Konsole/KDE 3).

Incidentally, the shiny new System Monitor tool in KDE 4 provides that figure in the 'Memory' column, instead of showing the rather less meaningful (and usually larger) VmSize figure. Which is great, because when non-expert reviewers compare a KDE 3 program (using KSysGuard) against its KDE 4 counterpart (using System Monitor) the figure for the KDE 4 program will be much smaller even if in reality the memory usage is the same. Why didn't we think of that before ;)

The bottom line though is that if you are running a process which is producing vast amounts of output, it will go noticeably faster if the terminal window on which it is being shown is not visible. Compiling doesn't usually produce such vast quantities of output that this is a problem, especially if you are building C++ programs where compilation takes much longer.

I personally do not think that catting a large file is not the most useful measure of terminal performance because it does not really affect how smooth and snappy it feels in day-to-day work. Something which does feel slow in Konsole and gnome-terminal compared with xterm is anything which involves scrolling text in a large terminal window, such as moving around a file in Vim, paging through a file or simply browsing output with the scrollbar.
This is where slowdown gets much more irritating, so that is what I put effort into fixing for KDE 4, along with quick startup (it will never be quite as snappy as xterm I expect).

Reply Score: 5

RE: Konsole
by martinus on Thu 6th Sep 2007 17:37 UTC in reply to "Konsole "
martinus Member since:
2005-07-06

I have used top, how do you measure memory usage?

EDIT: I should have finished reading :-)

Edited 2007-09-06 17:39

Reply Score: 1

The best terminal
by netpython on Thu 6th Sep 2007 15:35 UTC
netpython
Member since:
2005-07-06

is the plain old console without X..

Reply Score: 3

cat is a good test
by defdog99 on Thu 6th Sep 2007 19:41 UTC
defdog99
Member since:
2006-09-06

I think it's a useful test. Everyday people like me run grep on a 100meg file not knowing if it matches a couple lines or the whole thing ;-) Then you're smashing ctrl-c for a minute waiting for the terminals to catch up...

Reply Score: 1

Its not even April
by polyex on Fri 7th Sep 2007 05:17 UTC
polyex
Member since:
2007-07-11

I thought this post was a joke. I used to know a fiction writer who would spend tons of time preparing to write, setting up his work area, the right feng-shui etc. trying to make sure nothing limited him before starting his all important writing tasks. Needless to say his writing was lousy and he was full of himself too.

Reply Score: 2

misleading benchmarks
by hornett on Sat 8th Sep 2007 13:00 UTC
hornett
Member since:
2005-09-19

I'm not saying they're completely wrong because I get similar numbers here.

However, what I will say is that they are very misleading. To demonstrate, open gnome-terminal and run man gcc. Scroll up and down and witness choppy text. Do the same test in xterm and witness perfectly smooth scrolling, even if you use smooth fonts.

I don't know how to measure this lag, but it matters a lot more (to me anyway) that the speed a terminal can simply dump a volume of text in one go.

Edited 2007-09-08 13:01

Reply Score: 1