Plugin locator performance ballpark

[David Faure]

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?

100% of the current code uses the sync API, since it's the only one that 
exists.
So if we don't make it fast, all that code will be too slow.
Only newly written code using the async API will be OK.

If, instead, we ensure that it's fast enough, then sync call is ok, and the 
async api is rather useless.

The same logic could be applied to everything sync in Qt (QFile, QXml, etc. 
etc.). They don't provide thread-based async apis around that. Apps that want 
to move these operations to a thread, can just do that, on top of the sync 
query(). I tend to think the same applies to locating plugins.
All this means is that the trader must work from multiple threads, of course.

This is very different from e.g. network operations btw, since the order of 
magnitude is much bigger for those, and the timing is much less predictable.

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