"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