[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: icon loading (app startup) speed (longer)
From:       Antonio Larrosa =?iso-8859-1?q?Jim=E9nez?= <larrosa () kde ! org>
Date:       2001-08-11 2:57:00
[Download RAW message or body]

Well, this is an update with the comments from Richard, Matthias and Marc 
Mutz.



El Vie 10 Ago 2001 18:37, Antonio Larrosa Jiménez escribió:
> El Mié 08 Ago 2001 22:42, Waldo Bastian escribió:
> > On Wednesday 08 August 2001 12:30 pm, aleXXX wrote:
> > > I couldn't reliably measure how much time it saved,
> > > maybe 0.05 to 0.1 seconds, if at all ( on a K6/200) :-(
> >
> > I played around with this as well, (I think I did send you some
> > stuff), and I couldn't save much time their neither. The loading from
> > disk seems to be quite fast actually, also the stat() and access()
> > calls might seem a lot but the actual directory info is most likely
> > cached by the OS anyway. Things might be different over NFS though.
> >
> > There are two options that might be worth looking into:
> >
> > 1) Using some sort of icon server that allows us to share pixmaps
> > between processes on the X-server.
>
> I'd say this wouldn't be very benefical. It would make the icon loader a
> lot more complex, and it wouldn't have any significant speed benefit.
>
> I had a look some time ago at the icon loader problem some people seem
> to have with respect to speed (it's quite easy to blame the icon loader
> for the startup time the applications need). But is it really the
> problem there ?
>
> Reading this thread made me have a look at my investigations (which I
> think I already reported to some of you privately, but I had the mistake
> of not doing it publicly). In any case, I've made some new experiments
> and these are the results.
>
> I took Konqueror as an example of a big application that loads lots of
> icons (most probably, it's the application that loads more icons except
> perhaps for kicker, but in kicker they're loaded when creating the
> menus, so it doesn't matter).
>
> I modified the icon loader to use a "best case" method to load an icon,
> that is: I embeeded an icon into the sources using the qembed tool from
> Qt and then return always the same icon ignoring what icon was
> requested.
>
> These are the times I got by running "time konqueror" :
>
############
## Modified libs to a "better than best case" (QPixmap cached in the 
server)

Number of icons loaded : 27
Number of icons loaded : 451

real    0m5.732s
user    0m2.400s
sys     0m0.100s

real    0m5.894s
user    0m2.430s
sys     0m0.130s

real    0m5.749s
user    0m2.380s
sys     0m0.070s

real    0m5.759s
user    0m2.380s
sys     0m0.050s

real    0m5.736s
user    0m2.410s
sys     0m0.080s

mean real time : 5.774 seconds
mean user time : 2.4 seconds

Difference to the current case: 0.268 (user) seconds or 0.68 (real) seconds

Note that this case doesn't do _anything_. The first time an icon is 
needed, it's loaded from the embeeded data, converted to a QImage, and 
then moved to the X server so that the following times, the icon loader 
just returns the correct QPixmap (without applying any effects or doing 
any conversions).


> ################################
> ## Modified libraries to a "best (aka impossible to get) 
case"
>
> Number of icons loaded : 27
> Number of icons loaded : 443
>
> real    0m5.915s
> user    0m2.640s
> sys     0m0.060s
>
> real    0m5.996s
> user    0m2.570s
> sys     0m0.130s
>
> real    0m6.182s
> user    0m2.520s
> sys     0m0.110s
>
> real    0m6.104s
> user    0m2.580s
> sys     0m0.080s
>
> real    0m6.108s
> user    0m2.530s
> sys     0m0.120s
>
> ##############################
> ## Normal libraries
>
> real    0m7.036s
> user    0m2.690s
> sys     0m0.140s
>
> real    0m7.122s
> user    0m2.640s
> sys     0m0.120s
>
> real    0m5.948s
> user    0m2.600s
> sys     0m0.130s
>
> real    0m6.219s
> user    0m2.680s
> sys     0m0.140s
>
> real    0m5.942s
> user    0m2.730s
> sys     0m0.080s
>
> Konqueror takes around 2.668 (user) seconds to start.
> If it doesn't have to load all those icons, but have them on memory, and
> doesn't even apply the image effects, nor search through the
> directories, it takes around 2.568 (user) seconds to start. That's 0.1
> seconds difference for a best case which is impossible to get as effects
> will always have to be applied (however you get the icon).
>
> This is measured by adding a
> QTimer::singleShot(4000,this,SLOT(close())); line at the end of
> KonqMainWindow's constructor. The 4 seconds doesn't matter as long as
> Konqueror has time to create the list view part, as we measure the user
> time, not the real time.
>
> Another possibility is to use exit(1) instead of a SingleShot, so
> Konqueror exits really inmediately after creating the gui, that is,
> after creating the actions (thus loading the action icons) and calling
> createGUI(0L) (but without showing it on the screen). In this case, we
> get the following results:
>


In this case (using exit(1) to measure the time), the results are:

############
## Modified libs to a "better than best case" (QPixmap cached in the 
server)

real    0m1.560s
user    0m1.310s
sys     0m0.110s

real    0m1.591s
user    0m1.340s
sys     0m0.080s

real    0m1.526s
user    0m1.340s
sys     0m0.080s

real    0m1.571s
user    0m1.400s
sys     0m0.090s

real    0m1.874s
user    0m1.360s
sys     0m0.090s

Mean real time : 1.624
Mean user time : 1.35 seconds
Difference : 0.168 (user) seconds or 0.329 (real) seconds

That's again a difference against the absolutely best case: just returning 
always the same pixmap, without even having to search or load it (except 
by a search on a _very_ small QPixmapCache object, which mainly contains 2 
pixmaps).

Having said that, I still don't see any reason to make it more complex 
(think that this is with konqueror, which uses lots of icons, something 
like 478 icons, while most applications use much less icons (think about 
konsole) so the difference will be much less). I'd also think about the 
time spent in interprocess communication (which probably takes some time 
too) so I won't spend much time on it.

Btw, if someone wants to give it a try, I can suggest to have a look at 
KSharedPixmap in kdeui and KPixmapServer in kdebase/kdesktop.

> ################################
> ## Modified libraries to a "best (aka impossible to get) case"
> real    0m1.690s
> user    0m1.510s
> sys     0m0.060s
>
> real    0m1.761s
> user    0m1.420s
> sys     0m0.100s
>
> real    0m1.768s
> user    0m1.450s
> sys     0m0.070s
>
> real    0m1.782s
> user    0m1.420s
> sys     0m0.130s
>
> real    0m1.731s
> user    0m1.410s
> sys     0m0.100s
>
> ##############################
> ## Normal libraries
>
> real    0m2.452s
> user    0m1.510s
> sys     0m0.100s
>
> real    0m1.775s
> user    0m1.530s
> sys     0m0.090s
>
> real    0m1.808s
> user    0m1.520s
> sys     0m0.140s
>
> real    0m1.787s
> user    0m1.460s
> sys     0m0.140s
>
> real    0m1.945s
> user    0m1.570s
> sys     0m0.110s
>
> That makes 1.442 seconds for the best theorical case, and 1.518 for the
> current case, which makes a difference of 0.076 (user) seconds.
>
> Now, I wonder if it's really neccesary to add so much complexity to the
> icon loader just to save (much) less than 0.076 seconds (and I say "much
> less" because the slow part on KIconLoader is not the icon loader
> itself, but the applying of the effects).
>
> Btw, my home directory (the one displayed by the list view when starting
> konqueror) contains 46 directories and 24 files (including a sample
> variety with log files, txt, png, bmp, pdf, mpg, html, c files, unknown
> files and a core file).These tests have been run on a K7/800 Mhz with
> 128 Mb RAM.
>
> Of course, I'm not against any kind of optimization, but redesigning it
> and making it more complex just because of those 0.076 is not what is
> needed to optimize application start up.
>
> > 2) The actual QPopupMenu generation seems to take quite some time.
> > Maybe we can delay this somehow?
>
> I'd say that would be a much better approach.
>
> Btw, I attach the changes I made to do those tests.
>
> Greetings,
>
> --
> Antonio Larrosa Jimenez
> KDE Core developer  - larrosa@kde.org
> SuSE Labs developer - larrosa@suse.de
> http://perso.wanadoo.es/antlarr
> KDE - The development framework of the future, today.

[prev in list] [next in list] [prev in thread] [next in thread]