OSNews: http://www.osnews.com/story/18570/Comprehensive_Linux_Terminal_Speed_Comparison Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Mon, 06 Jul 2009 20:17:19 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com Guess those speed improvements paid off http://osnews.com/thread?268922 http://osnews.com/thread?268922 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. Wed, 05 Sep 2007 17:40:00 GMT donotreply@osnews.com (pllb) Comments More information would be useful ... http://osnews.com/thread?268924 http://osnews.com/thread?268924 Like what kind of system the test was conducted on and the quality of the network connection. Wed, 05 Sep 2007 17:43:00 GMT donotreply@osnews.com (Robert Escue) Comments Funny... http://osnews.com/thread?268926 http://osnews.com/thread?268926 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". Wed, 05 Sep 2007 17:45:00 GMT donotreply@osnews.com (whartung) Comments konsole memory consumption http://osnews.com/thread?268936 http://osnews.com/thread?268936 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 Wed, 05 Sep 2007 18:01:00 GMT donotreply@osnews.com (slougi) Comments RE: konsole memory consumption http://osnews.com/thread?268950 http://osnews.com/thread?268950 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 ;) Wed, 05 Sep 2007 18:16:00 GMT donotreply@osnews.com (evangs) Comments RE: More information would be useful ... http://osnews.com/thread?268954 http://osnews.com/thread?268954 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... Wed, 05 Sep 2007 18:21:00 GMT donotreply@osnews.com (sequethin) Comments RE[2]: More information would be useful ... http://osnews.com/thread?268962 http://osnews.com/thread?268962 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? Wed, 05 Sep 2007 18:28:00 GMT donotreply@osnews.com (evangs) Comments RE: Guess those speed improvements paid off http://osnews.com/thread?268969 http://osnews.com/thread?268969 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/ Wed, 05 Sep 2007 18:36:00 GMT donotreply@osnews.com (SEJeff) Comments RE[2]: More information would be useful ... http://osnews.com/thread?268973 http://osnews.com/thread?268973 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. Wed, 05 Sep 2007 18:41:00 GMT donotreply@osnews.com (martinus) Comments RE: More information would be useful ... http://osnews.com/thread?268974 http://osnews.com/thread?268974 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. Wed, 05 Sep 2007 18:42:00 GMT donotreply@osnews.com (martinus) Comments RE[2]: More information would be useful ... http://osnews.com/thread?268983 http://osnews.com/thread?268983 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 Wed, 05 Sep 2007 18:48:00 GMT donotreply@osnews.com (ssam) Comments RE[3]: More information would be useful ... http://osnews.com/thread?268986 http://osnews.com/thread?268986 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. Wed, 05 Sep 2007 18:51:00 GMT donotreply@osnews.com (evangs) Comments RE[3]: More information would be useful ... http://osnews.com/thread?268990 http://osnews.com/thread?268990 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.024Edited 2007-09-05 19:03 Wed, 05 Sep 2007 18:54:00 GMT donotreply@osnews.com (scott.tiger) Comments RE[2]: More information would be useful ... http://osnews.com/thread?268996 http://osnews.com/thread?268996 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. Wed, 05 Sep 2007 19:07:00 GMT donotreply@osnews.com (Ford Prefect) Comments wrong test http://osnews.com/thread?269018 http://osnews.com/thread?269018 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. Wed, 05 Sep 2007 19:28:00 GMT donotreply@osnews.com (pmarin) Comments RE: konsole memory consumption http://osnews.com/thread?269024 http://osnews.com/thread?269024 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. Wed, 05 Sep 2007 19:34:00 GMT donotreply@osnews.com (segedunum) Comments RE: wrong test http://osnews.com/thread?269026 http://osnews.com/thread?269026 Compiling is what most distro devs do, programmers do, source based distros do, package builders do, I call that eveyday use. Wed, 05 Sep 2007 19:37:00 GMT donotreply@osnews.com (SlackerJack) Comments thanks all http://osnews.com/thread?269027 http://osnews.com/thread?269027 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). Wed, 05 Sep 2007 19:41:00 GMT donotreply@osnews.com (sequethin) Comments RE[2]: wrong test http://osnews.com/thread?269038 http://osnews.com/thread?269038 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. Wed, 05 Sep 2007 19:51:00 GMT donotreply@osnews.com (pmarin) Comments Results from OS X http://osnews.com/thread?269049 http://osnews.com/thread?269049 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 Wed, 05 Sep 2007 20:09:00 GMT donotreply@osnews.com (CrimsonScythe) Comments RE: wrong test http://osnews.com/thread?269088 http://osnews.com/thread?269088
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? Wed, 05 Sep 2007 21:25:00 GMT donotreply@osnews.com (shapeshifter) Comments urxvt http://osnews.com/thread?269092 http://osnews.com/thread?269092 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. Wed, 05 Sep 2007 21:35:00 GMT donotreply@osnews.com (acobar) Comments xfce4-terminal http://osnews.com/thread?269102 http://osnews.com/thread?269102 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? Wed, 05 Sep 2007 22:09:00 GMT donotreply@osnews.com (Savior) Comments RE: xfce4-terminal http://osnews.com/thread?269118 http://osnews.com/thread?269118 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 Wed, 05 Sep 2007 22:46:00 GMT donotreply@osnews.com (Ford Prefect) Comments RE: urxvt http://osnews.com/thread?269139 http://osnews.com/thread?269139 "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) Wed, 05 Sep 2007 23:42:00 GMT donotreply@osnews.com (Doc Pain) Comments BeOS http://osnews.com/thread?269161 http://osnews.com/thread?269161 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. Thu, 06 Sep 2007 00:36:00 GMT donotreply@osnews.com (izomiac) Comments stupid question http://osnews.com/thread?269193 http://osnews.com/thread?269193 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? Thu, 06 Sep 2007 03:31:00 GMT donotreply@osnews.com (richmassena) Comments Console output limiting? http://osnews.com/thread?269202 http://osnews.com/thread?269202 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 Thu, 06 Sep 2007 05:30:00 GMT donotreply@osnews.com (renox) Comments RE[4]: More information would be useful ... http://osnews.com/thread?269226 http://osnews.com/thread?269226 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 Thu, 06 Sep 2007 09:58:00 GMT donotreply@osnews.com (antik) Comments RE: Console output limiting? http://osnews.com/thread?269233 http://osnews.com/thread?269233 Then you'd be measuring the performance of cat and not the performance of the terminal. Thu, 06 Sep 2007 10:37:00 GMT donotreply@osnews.com (evangs) Comments RE[2]: wrong test http://osnews.com/thread?269241 http://osnews.com/thread?269241 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? Thu, 06 Sep 2007 11:21:00 GMT donotreply@osnews.com (MrSidecar) Comments RE[3]: wrong test http://osnews.com/thread?269253 http://osnews.com/thread?269253 "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. Thu, 06 Sep 2007 12:17:00 GMT donotreply@osnews.com (Soulbender) Comments With compositing window manager, it's reversed. http://osnews.com/thread?269277 http://osnews.com/thread?269277 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. Thu, 06 Sep 2007 14:05:00 GMT donotreply@osnews.com (signals) Comments Konsole http://osnews.com/thread?269281 http://osnews.com/thread?269281 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). Thu, 06 Sep 2007 14:26:00 GMT donotreply@osnews.com (robertknight) Comments RE[2]: Console output limiting? http://osnews.com/thread?269286 http://osnews.com/thread?269286 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. Thu, 06 Sep 2007 14:58:00 GMT donotreply@osnews.com (renox) Comments The best terminal http://osnews.com/thread?269294 http://osnews.com/thread?269294 is the plain old console without X.. Thu, 06 Sep 2007 15:35:00 GMT donotreply@osnews.com (netpython) Comments RE: More information would be useful ... http://osnews.com/thread?269314 http://osnews.com/thread?269314 Sure!!! If he had tested with a gigabit network card installed, the results would change this much!!! O_o Thu, 06 Sep 2007 17:08:00 GMT donotreply@osnews.com (dopp0) Comments RE: konsole memory consumption http://osnews.com/thread?269317 http://osnews.com/thread?269317 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. Thu, 06 Sep 2007 17:20:00 GMT donotreply@osnews.com (looncraz) Comments RE: Konsole http://osnews.com/thread?269323 http://osnews.com/thread?269323 I have used top, how do you measure memory usage?

EDIT: I should have finished reading :-)Edited 2007-09-06 17:39 Thu, 06 Sep 2007 17:37:00 GMT donotreply@osnews.com (martinus) Comments cat is a good test http://osnews.com/thread?269363 http://osnews.com/thread?269363 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... Thu, 06 Sep 2007 19:41:00 GMT donotreply@osnews.com (defdog99) Comments Its not even April http://osnews.com/thread?269466 http://osnews.com/thread?269466 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. Fri, 07 Sep 2007 05:17:00 GMT donotreply@osnews.com (polyex) Comments RE[3]: wrong test http://osnews.com/thread?269467 http://osnews.com/thread?269467 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. Fri, 07 Sep 2007 05:21:00 GMT donotreply@osnews.com (polyex) Comments misleading benchmarks http://osnews.com/thread?269780 http://osnews.com/thread?269780 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 Sat, 08 Sep 2007 13:00:00 GMT donotreply@osnews.com (hornett) Comments