Review Request 111050: Fast mime detection speedup. Well over 10x faster.

[David Faure]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111050/#review34480
-----------------------------------------------------------


In addition to the issues below, I suspect it changes behavior with HTTP urls. But you'll find that out when actually running kmimetypetest.


kdecore/services/kmimetype.cpp
<http://git.reviewboard.kde.org/r/111050/#comment25309>

    The URL for a folder doesn't necessarily end with a slash.
    
    You can use the mode_t argument to detect folders, when it's set.
    If it's not set, you have to stat(), no other choice.
    
    Did you actually run kmimetypetest BTW? I expect a number of regressions, from this patch. I won't accept a patch which introduces regressions, however.
    
    (BTW all this code is dead code, I rewrote all of it for Qt5's QMimeType...)
    



kdecore/services/kmimetype.cpp
<http://git.reviewboard.kde.org/r/111050/#comment25310>

    WTH? Where did the support for icons specified in the XML file, go?
    
    Sure, you can make things faster by removing features... let's go back to Atari ST whose OS ran on 8 MHz CPUs?



kdecore/services/kmimetyperepository.cpp
<http://git.reviewboard.kde.org/r/111050/#comment25311>

    Adding DontResolveAlias to all lookups in this method is an interesting idea. Probably OK for inode/directory. But probably not for the application/* mimetypes: if someone changes freedesktop.org.xml in the future to make e.g. application/x-shellscript an alias rather than a canonical mime name, it will break this code. (And such changes do happen regularly). So I'd rather we don't do that (this code is only run once anyway).



kdecore/services/kmimetyperepository.cpp
<http://git.reviewboard.kde.org/r/111050/#comment25313>

    Basically the same as defaultMimeTypePtr(), but with race conditions for lack of the mutex, and without error handling in case the mimetype definitions are not found? For code that is run only once, what's the point?


- David Faure


On June 16, 2013, 4:42 p.m., Mark Gaiser wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111050/
> -----------------------------------------------------------
> 
> (Updated June 16, 2013, 4:42 p.m.)
> 
> 
> Review request for kdelibs, David Faure and Frank Reininghaus.
> 
> 
> Description
> -------
> 
> Hi,
> 
> I've recently seen Frank Reininghaus do his best in speeding up the rendering in dolphin with regards to the app icons. And trying to prevent icon flickering between "unknown" and the actual icon.
> 
> While reading his posts on the mailing list i was beginning to wonder: "is fast mime detection actually fast"? While it was certainly faster then "slow" mime detection, it still didn't really seem fast to me. A small benchmark app hat ran fast mime detection in /usr/bin took ~40ms to complete. That's for just 2656 items.
> 
> After quite a bit of profiling i managed to to bring the duration down from ~40ms to ~3ms sometimes ~4ms. That's well over 10x faster.
> Mime detection by extension (like "file.tar.bz") is done as follows:
> 
> file.tar.bz
> Loop - find first dot
> - "tar.gz"
> if that matches a mime type then it's returned if it doesn't then it proceeds on to the next dot:
> - next dot: "gz"
> if that matches.. return.
> Otherwise it will return the default mime type.
> 
> I am getting an inconsistency. Using the unpatched fast mime detection on a file like: "test.tar.gz" gets detected as "application-x-compressed-tar" where the patched version detects it as "application-gzip". The slow and detailed mime detection detects the same file as "application-x-compressed-tar". What should it be? application-gzip or application-x-compressed-tar?
> 
> Note: This improved detection does expect folders to end with a "/". Otherwise they will be detected as application-octet-stream (the default). But i think this is common sense to let folders end with a "/". If any apps that don't do that, they should fix it i suppose.
> 
> Best thing, it's all internal and private api change. No public function is changed.
> 
> All feedback is welcome! If possible, i would like to put this in KDE 4.11.
> 
> 
> Diffs
> -----
> 
>   kdecore/services/kmimetype.h bc35bcf 
>   kdecore/services/kmimetype.cpp d748523 
>   kdecore/services/kmimetyperepository.cpp f56f48e 
>   kdecore/services/kmimetyperepository_p.h e1d2389 
> 
> Diff: http://git.reviewboard.kde.org/r/111050/diff/
> 
> 
> Testing
> -------
> 
> Tested this using just output comparison between the old version and the new implementation. It works just fine.
> 
> 
> Thanks,
> 
> Mark Gaiser
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130617/02f92292/attachment.htm>