KConfig/KLockFile performance (was KMimeType performance)

[Maksim Orlovich]

> 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,
aka the cost of a first desktop startup. It slows done reading of any
global desktop or config file, which happens on app startup.

Please see the attached log file for ereslibre's scenario. There, we waste
~30ms of app startup time on trying to lock global files. And about 3.4
/seconds/ using the file dialog. Way beyond unacceptable for interactive
scenario.

It would be very good if people familiar with KConfig and KLockFile would
look into this. Actually, it would be very bad if they didn't

-Maks