JUL
23
2010
|
Mimetypes are out of ksycocaDuring the Akademy kde-on-mobile discussion, Kévin Ottens suggested that mimetypes be splitted out from the main sycoca database, in order to reduce the overall time kbuildsycoca takes every time it runs, and to make things more modular. Last monday I had a look and decided to go one step further and not use ksycoca at all for mimetypes. This makes the KMimeType subsystem really independent (usable without having run kbuildsycoca4 before, so no dependency on kdeinit+kded etc). Took me the whole week, but there we are. Given that shared-mime-info delivers pre-processed output already, we "just" have to load what we need, on demand, in-process. I was afraid this would be slower and take more memory as a result, but see results below. The KMimeType subsystem now loads directly from disk the information it needs. The first time you use findByPath("foo.jpeg") it loads the "globs" file generated by shared-mime-info once and for all into memory, and then uses that for fast matching. Same thing for the list of aliases (one big file, loaded once), and for "subclasses". The more expensive information is the XML file for each mimetype, but this is only needed when asking for the icon, the comment, or the list of extensions for a given mimetype. This used to be all parsed and cached into ksycoca, now it's done on demand by KMimeType. The only mimetype-related thing that is still in ksycoca is one tiny entry per mimetype, with a pointer to the list of services (applications) which support this mimetype, for KMimeTypeTrader. Here are the performance results:
I find it interesting how not using a cache that was invented to improve performance, actually improves performance :-) Interestingly, I thought it would be worse on memory usage too, but it's not: The "visual" result of all this: kdelibs-trunk$ kmimetypefinder foo.cpp (This particular use case of starting one process for one mimetype lookup has of course worse performance now, but it's time to stop looking at performance when it's about 0.01s vs 0.03s for a one-time operation...) Anyway the main point of these 2 commands was: no ksycoca needed. Writing all this makes me realize that the caching of kioslave .protocolinfo files into ksycoca is more like mimetypes than applications and even simpler: fewer items, and always used for looking up the details for a single protocol by name. So, logically I should extract it from ksycoca too. Well, after the vacations :) |
![]() |
Comments
Use mime.cache?
For possibly even better performance, you could mmap the pre-compiled binary mime.cache file that glib uses.
Wow, amazing these kind of
Wow, amazing these kind of improvements are still possible :D What made the ksyscoca implementation less efficient?
The reason ksycoca was slower
The reason ksycoca was slower in many cases is because it loaded all fields of kmimetype unconditionally, while this is now done on demand (so it's typically faster, for all these use cases which don't need the icon or comment, like mimetype matching or associate-apps lookup).