I had a discussion about the speed of Konsole with some Gnome users at a CodeYard meeting. Some testing on the spot revealed gnome-terminal was much faster. So I tried to test some stuff at home, too - see if anything has changed with KDE 4.
Well, yes, Konsole got almost twice as fast - still slower than gnome-terminal, though.
[root@wietbak log]# time cat messages.log.4
(lots of output)
real 0m1.923s (Konsole KDE 3)
real 0m1.077s (Konsole KDE 4)
real 0m0.412s (gnome-terminal 2.18)
But there are differences - some files show different results.
Take the output of another file, dunno what it's supposed to be but it's in /var/log, too, and contains many weird characters like these: ���E�Ms� �
[root@wietbak log]# time cat btmp
real 0m1.030s (gnome-terminal 2.18)
real 0m0.819 (Konsole KDE 4)
real 0m0.711s (Konsole KDE 3)
So for this file, the result is exactly the opposite, though the differences are much smaller.
Weird, weird.
Let's cat all files in /var/log, then, see what the overall scores are:
[root@wietbak log]# time cat *
real 0m10.797s (Konsole KDE 4)
real 0m18.940s (Konsole KDE 3)
real 0m6.524s (gnome-terminal 2.18)
real 0m16.423s (xterm)
For those who want to know how xterm does... Besides looking horribly (no anti-aliassing, and flashes horribly while scrolling), it sucks only slightly less than Konsole from KDE 3 in terms of speed.
Anyway, that confirms the first results. Konsole got almost twice as fast, but gnome-terminal is still a lot faster ;-)
Now of course Konsole kicks gnome-terminal in terms of features, but speed matters too ;-)
I'm not unhappy with the current speed (hey, twice as fast, that's good!) but there apparently is room for improvement. So let's see what the future (KDE 4.1?) brings...
Did you clear the file cache between tests? If not, the app tested after will be at an advantage compared to the app tested first.
ReplyDeleteKonsole in KDE 4 felt much faster than in KDE 3. So I'm happy with the improvements.
ReplyDeleteAnd I didn't find KDE 3 performance to be a problem, in normal use.
Now, if I had to find issues, it would not be konsole speed, but rather its problem handling certain Unicode scripts...
Try to cat konqueror.desktop to and scroll up and down to see shat I mean.
Hi Jos,
ReplyDeleteThose results are roughly what I see on my system too. gnome-terminal is indeed pretty fast at processing large numbers of lines of output.
I personally do not think this is the performance criteria which matters most in normal usage. The biggest change from KDE 3 to KDE 4 is smoother, faster scrolling - especially with large screens full of text. In KDE 3 when the window is scrolled the whole display is repainted. Konsole/KDE 4 makes a much better effort to only repaint newly exposed areas. This includes scrolling in applications such as Vim or less.
I guess gnome-terminal caught up, it used to be the other way around:
ReplyDeletehttp://www.kdedevelopers.org/node/1034
I do agree that interactivity is more important then text throughput generally.
This kind of speed is more or less an illusion, as I understand it. Gnome terminal is not particularly fast at drawing text, it just skips most of it as it flies by. Konsole just draws slightly more of it I guess.
ReplyDeleteOf course, what is the use case for this kind of speed, aside from speed comparisons? As long as the terminal is not taking up a lot of CPU time when text is scrolling by at a reasonable rate (during compiling), then everything is ok. perhaps that is a better test. Write a small program that outputs text at a constant speed and compare cpu usage.
You might look at the fonts being used. Scrolling text in KDE hits the cpu pretty hard with certain video driver setups. It seems less of a factor with on kubuntu gutsy than older releases so something has changed. Older nvidia binary drivers were a primary cause of this in the past and it's possible this has been fixed (somewhat). I don't think the font/cpu scrolling issue was ever a problem on gnome/gtk based apps but I've never tried them either.
ReplyDeleteKDE4 being better with this could also point to something different in the font rendering too.
You can just grab the scroll bar handle and flip it up and down a bit while watching cpu useage to see if you're affected by this.
I agree with those asking about what exactly is the usage case of this?
ReplyDeleteWhat is the point of throwing millions of characters in the screen if its so much that the user will never read it?
For any amount of text for which it actually makes sense to "cat", would the speed make *any* difference for the end user?
One of the points of
"early optimisation is the source of all evil" is that: "pointless optimisation is evil"
If you're after pure speed, then you might as well not bother painting anything other than the first and last pages of the outputted text. You can tell gnome-terminal is pretty close to that behaviour. It seems to paint about 3 refreshes when I cat several thousand lines. This makes it "fast" of course, but the scrolling doesn't feel smooth at all either. I actually prefer the konsole scrolling. It's reasonably fast, without making it obvious that it's skipping lots of text.
ReplyDeleteAs others already mentioned gnome-terminal is faster because it skips several parts. Konsole does not skip that much and therefore is slower.
ReplyDeleteA comparison with other systems and some more information can be seen here:
http://martin.ankerl.com/2007/09/01/comprehensive-linux-terminal-performance-comparison/
This topic was even discussed quite some time ago on the planet, but I do not remember who wrote it and atm I fail to find the information...
I *bet* you're using a TrueType font in your konsole.
ReplyDeleteI *bet* you can gain a multiplication of your speed once you use an X11 font.
See also here: http://www.kdedevelopers.org/node/1034
About caches etc: all this with warm caches (I run it twice, then three times, averaging results).
ReplyDeleteIs this a huge issue? Well, no, not really... Of course, it DOES make a small diff if you compile a lot ;-)
About the smoothness - I was (am) aware both gnome-terminal and Konsole are smart - not rendering every line of text. But gnome-terminal goes further in that regard. I just ran Konsole and Gnome-terminal at the same time, and indeed, Gnome-terminal doesn't look very nice. It flashes, while Konsole really scrolls. I also had a look at memory usage, it seems Konsole both uses less itself (11 vs 13 mb) and less shared memory (15 vs 18). When you've run a large textfile through cat, the memory usage of Gnome-terminal goes up to over 40, while Konsole goes to up to 15... And gnome-terminal doesn't even keep the full history (konsole does)!
Both Gnome-terminal and Konsole use the exact same font & size. xterm - fully aliassed - yet slower.
"I also had a look at memory usage, it seems Konsole both uses less itself (11 vs 13 mb) and less shared memory (15 vs 18)."
ReplyDeleteYou also need to consider pixmap usage - make the konsole and gnome-terminal the same size on screen, and run xrestop (you might need to install it first - the package is usually called xrestop).
Qt4's purported reduced memory usage is basically a myth: sure, the process uses less memory as reported by top, but Qt4's double-buffering means that it takes a huge amount of x-server memory, especially if you maximise apps on a high-ish res screen.
Hopefully they'll provide a way of switching this off by default as it gobbles up memory and is completely and utterly useless in a composited environment.
Hey Jos, I just got some interesting results. I wrote a small program to output text to the screen. It just writes one line to the output, 2000 times a second.
ReplyDeleteSo I set up konsole and gnome terminal windows to be the same dimensions (~1000x1000 pixels).
Then I executed my program and checked top for CPU usage.
When the program is run in konsole, konsole uses approximately 18% of the cpu (Core 2 Duo 6700) and Xorg another 0 to 1%.
Now when I run the exact same program in gnome-terminal, gnome-terminal uses only about 11%, but Xorg is using 85 to 87%! So running my program in gnome-terminal actually maxes out the cpu. Looks like Gnome-terminal has some serious painting issues. (Proprietary nvidia drivers on a 7600gt or some such)
Blog software doesn't like code, but the pertinent lines are:
while(true) {
cout << c++ << "asdkjahsd kajshd klajjhd ajsdh aljkshd kljahsd ahdk jah shdakljhsk ljahsdljahsldlaksjda" << endl;
usleep(500);
}
@anonymous
ReplyDeleteFrom the Qt docs:
Qt 4 supports double buffering transparently on all platforms. This feature can be turned off on a per-widget basis by calling QWidget::setAttribute(Qt::WA_PaintOnScreen).
So if you want to get your memory back, just set that attribute on all your widgets. I agree that it would be nice to have a global flag for this though.
@Leo S (first): interesting result. And weird issue... Maybe it can't skip blocks now cuz the text comes 2000 times a second, not continuously.
ReplyDeleteAbout the doublebuffering, is that really not needed with compositing?
@jos
ReplyDeleteYou're probably right that it is forced to update every line. Shows that there are some issues with redraw in gnome-terminal, but I wonder if things would change if I write out a page at a time instead of a line... Yes, the results are very different. If I write out about 10 lines at a time (200 times a second), konsole uses 9% cpu, while gnome-terminal uses 5% + 25% for Xorg.
Now if I output lots of lines at a time (like 50), then konsole jumps to 32%, while suddenly gnome-terminal only uses about 4%, and no more Xorg usage.
So gnome-terminal is fast when it doesn't have to draw much, while konsole draws much faster, but also draws more often. If you look at compile output, it is usually 1 to 10 lines at a time, so I think konsole's strategy works better for that workload.
Also, yes, if you have a compositing window manager, double buffering is not needed. For example, Qt does not enable its own double buffering on OS X. I assume that compositing is still rare enough on Linux that they've enabled it so that everyone will get the benefits of flicker free drawing. It sure would be nice if Qt could somehow detect if compositing was active and disable its own double buffering.
@Leo S: If qt detects compositing on Mac and disables the doublebuffering (or just disables it on mac, mac always has compositing) they should be able to do that on linux. So I guess they will - sometime or another.
ReplyDeleteaterm ftw!!! bloat vs bloat vs bloat so what is gnome-terminal is the fastes of those.
ReplyDelete"But there are differences - some files show different results. Take the output of another file, dunno what it's supposed to be but it's in /var/log, too, and contains many weird characters like these: ���E�Ms� � [..] Weird, weird."
ReplyDeleteFail.