[plasma-framework] src/plasma: Look up dataengines in kf5/plasma/dataengines

2013-09-25 Thread Sebastian Kügler 
Git commit 5b33844a0b9e49759289dc839a31c0bc8f417d37 by Sebastian Kügler.
Committed on 25/09/2013 at 23:34.
Pushed by sebas into branch 'master'.

Look up dataengines in kf5/plasma/dataengines

This changes the path where to find dataengines to the
subdirectory-per-servicetype setup.

Note: You'll need to update and reinstall kde-workspace/plasma, to
install the dataengines into the new path.

CCMAIL:plasma-devel@kde.org

M  +1-1src/plasma/pluginloader.cpp

http://commits.kde.org/plasma-framework/5b33844a0b9e49759289dc839a31c0bc8f417d37

diff --git a/src/plasma/pluginloader.cpp b/src/plasma/pluginloader.cpp
index 20a89b4..4991492 100644
--- a/src/plasma/pluginloader.cpp
+++ b/src/plasma/pluginloader.cpp
@@ -117,7 +117,7 @@ QString PluginLoaderPrivate::parentAppConstraint(const 
QString parentApp)
 PluginLoader::PluginLoader()
 : d(new PluginLoaderPrivate)
 {
-d-pluginDir = kf5;
+d-pluginDir = kf5/plasma/dataengine;
 d-isDefaultLoader = false;
 }
 

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [plasma-framework] src/plasma: Look up dataengines in kf5/plasma/dataengines

2013-09-25 Thread Aaron J. Seigo 
On Wednesday, September 25, 2013 23:43:43 Sebastian Kügler wrote:
 This changes the path where to find dataengines to the
 subdirectory-per-servicetype setup.

for shit’s ‘n giggles: has anyone done any performance profiling of this new 
system?

-- 
Aaron J. Seigo
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [plasma-framework] src/plasma: Look up dataengines in kf5/plasma/dataengines

2013-09-25 Thread Sebastian Kügler 
On Thursday, September 26, 2013 01:50:54 Aaron J. Seigo wrote:
 On Wednesday, September 25, 2013 23:43:43 Sebastian Kügler wrote:
  This changes the path where to find dataengines to the
  subdirectory-per-servicetype setup.
 
 for shit’s ‘n giggles: has anyone done any performance profiling of this
 new  system?

Yes: It's slower. I've run some tests on both, SSD and rotating rust 
with small, large, and huge plugin directories. In the best case (warm 
caches, reasonable directory size), we're within an order of magnitude of 
ksycoca (800%). Obviously, keeping the number of plugins per directory small 
makes it faster.

You can find numbers of the SSD runs in my email Plugin locator performance 
ballpark to kde-frameworks-devel from September, 5. I haven't cleaned up my 
measurements on rotating metal.

Especially on startup of Plasma, we'll get quite a performance hit. I think we 
can avoid that in part by caching the KPluginInfo::Lists for maybe just a few 
seconds in Plasma::PluginLoader. That means that most of our consecutive 
queries run over cached lists, making them orders of magnitude faster. That 
should save a hell of a lot of IO during start-up, while keeping memory usage 
in check.

Bottom line, if we're still not happy with the performance, we might need an 
on-disk cache in KPluginTrader, but the complexity of keeping that up to date 
with a system as flexible, dynamic and component-driven as Plasma, is 
something, say, worth avoiding.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [plasma-framework] src/plasma: Look up dataengines in kf5/plasma/dataengines

2013-09-25 Thread Aaron J. Seigo 
On Thursday, September 26, 2013 04:21:21 Sebastian Kügler wrote:
 You can find numbers of the SSD runs in my email Plugin locator performance
 ballpark to kde-frameworks-devel from September, 5. I haven't cleaned up
 my measurements on rotating metal.

oh wow, that is not encouraging. :/ i’m suddenly less enthused by this idea.

 Bottom line, if we're still not happy with the performance, we might need an
 on-disk cache in KPluginTrader, but the complexity of keeping that up to
 date with a system as flexible, dynamic and component-driven as Plasma, is
 something, say, worth avoiding.

problem is that 100-300ms on a high end machine is not acceptable. 

given that we load plugins at various times during execution based on user 
interaction, this will not just impact on startup, but during runtime.

 without a cache we’d end up having to do something truly fun like put the 
lookups in a thread, keeping an in-memory cache ... not something i expect we 
can ask of every application developer, either. basically what dfaure said in 
the kf5-devel thread.

he also noted that it would be possible to use a cache that is updated when 
the item gets put on disk. e.g. as part of “make install”. that would be 
rather fantastic and probably resolve the issue entirely.

-- 
Aaron J. Seigo
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel