Some optimization opportunities

[Daniël Mantione]

On Sat, 19 Jun 2004, Alexander Neundorf wrote:

> Yes, icons are searched in a lot of directories, I found the same thing when I
> running KDE on my old K6/200, but it's now almost 2 years ago.
> On my current system (AMD Athlon XP 2000+) it looks like this

Yes, if your computer is 10 times faster, the system calls get 10 times
faster too :) Still I'm surprised the system calls have so much overhead,
I remember a 486 could do about 1500 real/protected mode switches a second,
if I look at this Linux can do only several 1000s of system calls a second
on a k6.

> I'm afraid changing the search behaviour might break apps which rely on it.

Well, I guess the app simply searches for "www.png" and the KDE libraries
try to find the file, so changing it would not necessarily break things.
But I'm just an outsider...

> But it would be nice if you could spend some time to improve this issue.

Well, I'm not a KDE developer, my "home" open source project is the Free
Pascal compiler, so I'm more a user than a developer. As how to improve
it, I can think of several things. Since I'm a big fan of the KISS
principle, my personal favourite would be that the multiple
directory support gets kicked out, and only search in well known
directories. As this could introduce a maintainability issue, applications
might then slowly be changed to ask for directory/picture.png instead of
picture.png.

Another possibility is to scan directories first and remember which file
is in which directory. However, this has the disadvantage that every
KDE application increases it's memory usage as the user copies more icons
on his system.

> > Lastly, there are some unnecessary system calls while loading the image.
> > "fstat64" is being called twice and the "_llseek" system call is a nop.
>
> Well, I think calling stat() twice instead of once is something we can live
> with.

One efficiency is no problem of course, I'm just reporting them :)

> > Apparently a lot of memory is needed here, only it is allocated 4kb at a
> > time. It's unclear how many system call overhead there is, as likely a lot
> > happens between each system call. It is however interresting to see that
> > it takes about 90 ms to parse qtrc (the time between opening and closing
> > the file), which is a lot compared to decompressing the png files. 20 kb
> > of memory is allocated, qtrc is 6529 bytes large.
>
> AFAIK this is inside Qt. 90 ms is quite long. Parsing an average .desktop file
> with KConfig takes approx. 10 ms (on a K6/200). So loading qtrc can probably
> be optimized, but this happens only once while a KDE app starts, so not that
> much win  (... ok 50 ms would be actually a win). Maybe you can do something
> about it in Qt ?

Perhaps. Again, I'm not a KDE developer. Sending a bug report to Trolltech
might be an idea though. If I look at the amount of KDE processes in
memory, nrealy a second was wasted starting them.

> > Calling gettimeofday this often seems a little strange to me and certainly
> > an important part of the 35 ms here is wasted due to system call overhead.
>
> Do you know where this happens ? It must be some loop where nothing else
> interesting happens I think.

It seems to happen after loading up.png, and before loading
konq_history. /etc/passwd is opened just before it.

> > I hope this info is usefull in further optimizing KDE. I am not subscribed
> > to this list, however I will monitor the archives the next days.
>
> There's not that much traffic here, so it would be nice if you could
> subscribe.
> Helping hands in optimizing KDE are alwas needed :-)

Well, I can but since Free Pascal takes up a lot of my "free software
time", I'm afraid it won't be very usefull.

Greetings,

Daniël Mantione