Plugin locator performance ballpark

David Faure faure at kde.org
Tue Sep 10 09:25:23 UTC 2013


On Monday 09 September 2013 17:10:25 Martin Graesslin wrote:
> On Monday 09 September 2013 16:48:05 David Faure wrote:
> > On Monday 09 September 2013 14:23:10 Sebastian Kügler wrote:
> > > Martin Grässlin asked if we could offer an async API for this. Opinions?
> > 
> > This task is mostly I/O, and a bit of CPU.
> > Portable async I/O requires doing it in a thread.
> > To avoid setting up a thread every time, this could use QThreadPool (but a
> > dedicated one, to avoid blocking the main one which is supposed to be
> > about
> > pure-CPU operations only), and the runnable would call the sync trader
> > API.
> > 
> > So, it's feasible.
> > But is it worth it?
> 
> Just adding the reasoning why I suggested it. We tried (in KWin) to move all
> the querying to a thread. It utterly failed due to KGlobal not being thread
> safe. The code is still there, so I will probably switch with frameworks 5.
> 
> In KWin all the plugin loading is during start up, but none of them is
> essential. By making it async we can significantly improve the startup time
> - that is the time till the first frame is rendered and the splash screen
> unfreezes.

Ah, but you say "plugin loading", not just "locating plugins" (which was what 
my previous email was about).

Surely loading (which means creating the objects in the plugin) in a secondary 
thread requires a lot of extra care. The plugin authors won't expect that, 
they'll create QObjects, which will then live in the wrong thread -- or there 
will be races with the init in the main thread...

> Finding a large number of plugins at startup is - I assume - relevant to
> many applications, for example Plasma. If we have the API in a way that it
> makes async usage easy I think it would help a lot and sync usage is still
> possible: .waitForFinished().

If the app wants to actually load plugins in a thread, it needs to manage that 
thread. It's not just a one-time task with a result, like locating plugins and 
returning a QStringList or so. It's now a longer-living thread, with 
synchronization issues.
These large apps can do the plugin loading in a thread, but they'll have to 
handle the synchronization issues. I don't see a way to encapsulate all of it, 
it sounds rather dangerous (apps will not use proper synchronization then).
The difference with KDE4 is that there's no KGlobal anymore :) So now what you 
tried should be possible.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5



More information about the Kde-frameworks-devel mailing list