[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