KConfig/KLockFile performance (was KMimeType performance)

[Lubos Lunak]

On Tuesday 09 of October 2007, Maksim Orlovich wrote:
> > Hi all,
> >
> > First of all: I know we should concentrate on _make things work_ right
> > now,
> > but we are facing a critical performance regression on KMimeType class.
> >
> > You can try to see "live" this problems:
> >
> > - Open KWrite. Click on open so the open dialog is shown. Open
> > "/usr/include"
> > (with the icon view), fast, huh ? Now switch to detailed view... omg.
>
> The problem here isn't really KMimeType. What happens is that
> KFolderMimeType looks for a .directory file to get a comment, and uses a
> KDesktopFile to read that. KDesktopFile/KConfig tries to lock the file
> with KLockFile. KLockFile can't, no permissions in /usr/include, so it
> tries to back off and try again... and it takes ~10ms doing that, per each
> call to KFolderMimeType::comment(), which there are tons of.
>
> This is a pretty serious performance regression for many cases. If my
> measurements are right, it adds ~4 seconds to a cost of full KBuildSycoca,

 No, worse, it adds the cost of full KBuildsycoca, because those 
temporary .lock files cause changed timestamps, triggering full kbuildsycoca 
run every single time (as soon as it manages to actually create at least one 
of those files).

> aka the cost of a first desktop startup. It slows done reading of any
> global desktop or config file, which happens on app startup.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz