[RFC] [kservice] KPluginMetadata indexing

Sebastian Kügler sebas at kde.org
Thu Nov 6 15:43:25 UTC 2014


On Thursday, November 06, 2014 10:09:51 Mark Gaiser wrote:
> I'm curious about one thing. Have you done some profiling on the
> current KPluginMetaData to see where the actual hot spot is?
> In case you don't know how to do that, here are some tips:
> 1. Recompile Qt with debug symbols (not debug mode, just with the debug
> symbols) 2. Run a benchmark application via valgrind like so: valgrind
> --tool=callgrind <your_benchmark_app>
> 3. Open the output file of the line above in KCacheGrind and hunt for
> those pesky hot spots.
> 
> Perhaps there is nothing to optimize and then having an index (and the
> cost of maintaining it) is worth it, but it would be best to first
> determine if the current code path can be optimized.

I've focused on reducing the I/O, since that's where we spend by far most of 
the time, somewhere beyond 90% of the whole time it takes to run the query 
(and in worse cases with cold caches and on rotational media, even more). 

The next bottleneck would be the deserialization of json data, which is for 
the binary format we use for storage (and I think which is also used in 
QPluginLoader to read the plugins json metadata). As fas as I can see, that is 
also pretty much entirely I/O bound.

There may be something to be gained in the conversion from the KPluginMetaData 
list to the KPluginInfo::List by making the query runner 'understand' 
KPluginMetaData (it knows KService and KPluginInfo currently) but that's 
definitely not a bottleneck currently. 

In the whole picture, KPluginMetaData is not a concern right now, reducing the 
I/O is what we need to do first. 

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


More information about the Kde-frameworks-devel mailing list