Plugin locator performance ballpark

[Sebastian Kügler]

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