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

List:       kde-core-devel
Subject:    Re: Speed issues on app load
From:       rik () kde ! org
Date:       2000-12-20 22:11:57
[Download RAW message or body]

#if Dirk Mueller
> On Mit, 20 Dez 2000, rik@kde.org wrote:
> 
> > According to strace -r, a lot of time is spent in things like mmap
> > and mprotect stuff, which I think is shared libraries being mmap-ed,
> > but I don't think this is the only problem. It seems every single
> > font on my system (1662 total) is opened, so there's something up
> > with the X font loading there. I've reduced that by temporarily
> > disabling nearly all of my fonts.
> 
> Huh???? Do you use the libXft by accident ?

I use it on purpose :) Loads of debug info and it opens every font,
but if you delete all your fonts it works well ;)

> > Anyone care to guess how we can ask the system to be nice and load
> > apps faster ?
> 
> Upgrade to kernel 2.2.18, the 2.2.17er had _serious_ bugs in the LRU
> caching. 

Ok, thanks.

> Besides that, compiling Qt without XIM support helps a lot as well. I don't
> why that stuff is so fscking slow but it is. 

Yes. 100ms off startup for me.

> Konsole is still a special evil case as it does a huge amount of useless and
> timeconsuming stuff during startup. 

Yes, I know about konsole :) But all other KDE apps have the same
trouble. See my timings for keditbookmarks. 7s extra when it hasn't
been used for a while. This makes me think it's Linux, not KDE. I can
cope with waiting 2s for an app to start. It's annoying, but it's
acceptable. 9s is just silly. By that time I've started doing something
else.

> Well, I'm still seeking for the performance holes, its not that easy to
> find. The XML Gui / KAction stuff is definitely very slow, I hope that we
> can improve in that part a bit. David and Simon did a lot of investigation
> there already and I intend to look into it as well, next year ;)

I can confirm this. I had a look through konqy's code to see why it
took so long to open a new (blank) window. The bulk of the time was
taken in createGUI() and createBrowserWindowFromProfile().

With an optimised build (--disable-debug) it's < 1s to open a new
window, which is almost usable. Sadly the menu is left visible but not
repainted while this happens, so it's quite ugly. It would be nice if
QPopupMenu was able to wait until the menu had closed before emitting
the 'activated' signal, for non-checkable items anyway.

Rik

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