Hi,
I've had a look at the performance of loading plugins.
First, some background: We've taken the first steps towards moving away from
KSyCoCa for plugins. By including metadata in the plugin, we don't need to
keep the metadata installed (via .desktop files) and indexed separately, but
can get this information out of the plugin binaries themselves.
QPluginLoader::metadata() (and friends) is the corresponding API. For
retrieving the metadata, the plugin doesn't have to be opened completely, so
just reading the metadata from a plugin is supposed to be "comparably fast".
What does that mean? What's the performance impact when we query the
individual plugins for their metadata?
So, I've written a small test case to get a rough idea of what performance
we're looking at. The tests are rather unscientific, but gives at least an
idea of the order of magnitude.
I've looked at the following:
(0) How long does it take to find a plugin using KServiceTypeTrader::query()
(so going through sycoca)?
(1) How long does it take to query a whole bunch of plugins for their
metadata, so we can find them? (This test does a lot less than (0), it
just reads the metadata, creates a KPluginInfo from it, and then throws it
away.)
Some figures:
Cold caches:
Reading just $PLUGINS/kf5, 52 plugins
21893.0 microsec (KServiceTypeTrader)
95835.0 microsec (Metadata)
--> Reading metadata is 4-5 slower, ~100ms
Reading $PLUGINS recursively, 127 plugins
20180.0 microsec (KServiceTypeTrader)
347083.0 microsec (Metadata)
--> Expectedly, gets worse with more plugins, ~300ms
Warm caches:
Reading just $PLUGINS/kf5, 52 plugins
943.0 microsec (KServiceTypeTrader)
6656.0 microsec (Metadata)
--> about 8 times slower
Reading $PLUGINS recursively, 127 plugins
1399.0 microsec (KServiceTypeTrader)
16421.0 microsec (Metadata)
--> we start losing frames here for sure
Some thoughts:
* I've done these measurements on a pretty fast system (Core i7 + SSD), so the
numbers we're looking at are likely a best case scenario. I'll have a look
at the numbers on rotating metal.
* ksycoca performance is probably a pretty good orientation value
* the number of plugins will only go up, so that's going to mean we'll likely
end up a few times slower, this is pretty linear growth
* the tests show quite some variance (up to 50%), but overall, the numbers are
explainable
* In terms of time-budget, keep in mind that if we want to produce 60 frames
per second, we'll have a time budget of less than 16 milliseconds, or we
start losing frames
* The tests kind of assume that the actual filtering and searching doesn't
really matter compared to the I/O
KServiceTypeTrader uses synchronous API currently. If we want to keep this
API, and thus portability manageable, we'll have to do some performance tricks
(e.g. caching).
Overall, I think performance of this isn't too horrible, given that we're
really traversing the filesystem, opening and reading from a whole bunch of
files.
I'll work further on refining the plugin location mechanism, just wanted to
share these -- I think quite interesting -- numbers.
Code is in kdelibs[sebas/pluginlocator]/staging/kservice/.
Cheers,
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
