Plugin locator performance ballpark

Alexander Neundorf neundorf at kde.org
Sun Sep 8 09:33:06 UTC 2013


On Sunday 08 September 2013, David Faure wrote:
> On Thursday 05 September 2013 01:04:52 Sebastian Kügler wrote:
> > 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
> 
> This is why I think we want an API that is slightly different from
> KServiceTypeTrader: we want a subdir name into which to narrow the search.
> 
> Queries for calligra plugins should only look in $PLUGINS/kf5/calligra/
> Queries for KCModules should only look in $PLUGINS/kf5/kcmodules/
> Queries for kio_thumbnail plugins should only look in
> $PLUGINS/kf5/thumbcreator/
> etc.
> 
> i.e. turning every "service type" into a subdir name. But for more complex
> cases (e.g. a plugin implementing multiple servicetypes) we can still use
> additional constraints in the metadata of course.
> 
> Querying into a plugins subdir is more Qt-like, too.
> 
> However Boud said calligra had 300-400 plugins, so under calligra alone
> we'd have the same performance as what you just measured for all of
> $PLUGINS/kf5. 300 ms cold cache, 16 ms warm cache. Boud, any opinions? :-)

And that's with SSD, numbers for a normal hard disk might be quite higher.

Alex


More information about the Kde-frameworks-devel mailing list