KFileItem optimization

[Jakub Stachowski]

Dnia Monday 05 January 2009, David Faure napisał:
> On Saturday 03 January 2009, Jakub Stachowski wrote:
> >  It is slow operation, because of mime-
> >
> > >is("application/x-desktop") check, which constructs KMimeType object for
> >
> > application/x-desktop type again and again.
>
> Yep. I have on my todo list "optimizing KMimeType::is by adding a way in
> ksycoca to get a mimetype's parent without having to load it completely".
>
> > Attached patch adds fast path to
> > KMimeType::is by allowing to ignore resolving aliases. It is not a
> > problem in case of KFileItem, because application/x-desktop is not an
> > alias.
>
> Well, it is not at the moment, but who knows about the future?
> Any mimetype could be turned into an alias later on in order to solve some
> bug, like if we merge two mimetypes.
>
> Also, this is solving the wrong problem IMHO. Resolving aliases _is_ fast,
> since they are in a QMap in KMimeTypeFactory. The problem is just that
> findMimeTypeByName does both: resolving aliases _and_ loading the mimetype,
> which is the slow part. How about we resolve aliases without loading the
> mimetype? This would solve this in a much nicer way - no need for new API,
> the code would remain generic but just faster.
>
> Can you check the performance with this new patch?
> (This is orthogonal to my planned KMimeType::is() performance improvement
> which would make it even faster, btw).

Only slightly slower than my patch (~9% instead of ~7% CPU spent in 
KFileItem::iconName()  ). But at least it is future-proof.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-optimize/attachments/20090105/0b4285bc/attachment.htm