Plugin locator performance ballpark

[Martin Graesslin]

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.

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().

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130909/17e16453/attachment.sig>