"proofs" about Konsole
Lubos Lunak <[email protected]> Tue, 2 Nov 2004 13:02:30 +0100
| Newsgroups | gmane.comp.kde.devel.optimize |
|---|---|
| Message-ID | <[email protected]> |
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: [email protected] , [email protected] Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/