On Sunday, September 08, 2013 11:17:56 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
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
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
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
On Sun, 8 Sep 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
On Sun, 8 Sep 2013, Boudewijn Rempt wrote:
I like the directoryname idea, and actually, I'd go for a hierarchy:
calligra/filter
calligra/parts
calligra/words
calligra/krita/paintop
calligra/krita/filter
calligra/krita/extensions
etcetera. that should limit the number of plugins per directory
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
