"proofs" about Konsole

Lubos Lunak l.lunak at suse.cz
Tue Nov 2 13:02:30 CET 2004


 Hello,

 I've noticed two "benchmarks" about how lightweight Konsole actually is :
http://aseigo.blogspot.com/2004/10/konsole-vs-xterm-or-proof-that-kde-is.html
http://aseigo.blogspot.com/2004/11/ah-but-start-up-times.html
 And I've also noticed some people wanting to make that a dot story. Not that 
I'd be against it, we certainly could use some PR in this area, but, sorry to 
spoil the fun, with some bad luck we could look pretty clueless. While with 
benchmarks it's possible to do a lot of magic (lies, damned lies, and 
statistics), there at least shouldn't be such technical mistakes:

- using RSS for measuring memory usage is plain wrong, at least as long as 
it's not explicitly stated that swap is not used. RSS is, quoting from 'man 
ps', "resident set size, the non-swapped physical memory that a task has 
used". Just causing some swapping activity can mean RSS values change 
completely, and the values stated for konsole and xterm can be simply some 
random values. Measuring memory usage on Linux is a black magic, AFAIK a good 
way of measuring memory usage of one app is using either the total memory 
usage of the process, or total-shared for the unshared portion.

- the trick with kstart "improving" startup time of konsole is most probably 
just the fact that with "time kstart konsole -e bash -c exit" it's no longer 
the time of konsole measured, but it's only kstart. This command is actually 
not stated explicitly anywhere, but I presume it's the one. I don't see any 
good reason why kstart should improve the time.

- it should be also noted that things like fontconfig and XIM have a 
significant share in memory usage, so they can grow memory usage of one 
process by say 1M, affecting the relative comparison.

 The memory numbers actually don't seem to be wrong, at least from a certain 
point of view. Here, with KDE running, Konsole with two tabs really seems to 
be better than two xterm's.

 But the same way I could also claim that it cannot beat rxvt as long as there 
are not more than 10 rxvt's running, and when not running KDE the same holds 
true for 10 xterm's (because of kdelibs).

 So if you want to spread the word, please at least fix the RSS thing.


BTW, "yes, we have a LOT of optimization possibilities ahead of us" - care to 
list some that'd make a noticeable difference and wouldn't involve such 
insanities like switching to plain C or, heaven forbid, assembler? I may be a 
bit pessimistic, but I can hardly see more than a handful of SANE 
optimization possibilities.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/


More information about the Kde-optimize mailing list