"proofs" about Konsole

[Aaron J. Seigo]

On Tuesday 02 November 2004 05:02, Lubos Lunak wrote:
>  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.ht
>ml http://aseigo.blogspot.com/2004/11/ah-but-start-up-times.html

the second was supposed to use kdeinit_wrapper not kstart. my goof, but the 
fact still stands its faster. i'll note this in a future blog entry.

anyways, thanks for reading my blog, that's pretty cool...

> - 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 experiment has been repeated on several machines by several people all 
coming to the same conclusion, so i'm pretty confident the numbers are good. 
the machine i did the test on swap was not even being touched (it has a gig 
of ram and i hadn't actually done anything on the machine yet that day 
besides read email, web and irc ;), but more importantly the numbers are 
repeatable and in line with expectations. they may be a 100K out this way or 
that, but i doubt with the numbers we're talking about, and the numbers 
actually seen, that they were out any.

note that my blog is not intended to be a scientific paper, but a message to 
the masses to stop the "KDE is bloated" crap that i'm tired of hearing.

>  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).

well, that was sort of the point of my blog: "if you use multiple sessions, 
you will see a win". =) my experience has been that a lot of CLI-in-X users 
have more than a couple sessions open, and that these are precisely the ones 
who complain about konsole being heavy. which is ironic. which is why wrote 
that blog entry.

> 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.

sure. i just finished doing optimizations in the taskbar, where we were 
iterating over the list of tasks in task buttons every time we moved a 
window. *MOVED* a window! even on valid events, we were iterating over the 
same lists 2 or 3 times. 

when looking for the common part of the taskbar button text when grouping, for 
N tasks with L=strlen(N(1)) we'd do up to ((L-1)*N) QString::left()s and 
QString::==s in just ONE of the loops. this was easily rewritten to compare 
the characters one at a time and keep track of where we were with an int.

the end result was the removal of several bugs complaining about taskbar 
buttons visibly flickering, which was visible only because it was doing 
things as slowly as possible as often as possible.

before i looked at the taskbar code i could never have guessed it was like 
this. in other words, i don't have a tidy list in my back pocket of places in 
the code we should attack with full gusto to make KDE as efficient as 
possible. but based upon my experience in the code base, i'd say there are a 
LOT of places things could be written more efficiently.

another example of this would be in kdepim land, where a lot of work has gone 
into making kmail faster, with a lot of success over the past couple years. 
just recently someone noted that korgnizer writes out the complete calendar 
file on *every* edit. 

konsole got as fast as it did because of work on delayed loading of things. it 
could probably be even faster in starting up if it didn't use bookmarks and 
link in libkio. (that's just a WAG, though)

in the end there are no easy magic wands to wave here. just a lot of work.
and i'm glad that the blog has sparked dialog. dialog is the first step 
towards solution.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20041102/dbad0f3d/attachment.pgp