KFileItem optimization

[David Faure]

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).

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inherits_speedup.diff
Type: text/x-diff
Size: 2126 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20090105/1cc3b06e/attachment.bin