[Nepomuk] Redundant DBus communication

[David Faure]

On Sunday 13 January 2013 15:26:54 Vishesh Handa wrote:
> Hey David
> 
> This is normal. Some one is asking for the changes, and that is why the all
> those dbus signals are being emitted. We only emit these
> changed/added/removed signals if someone requests them. 

Yes, but why emit Added and then Changed, with the exact same data in the signal? What is the purpose of emitting Changed, if nothing changed since the Added signal? Surely the number of signal emissions could be cut in half, by only emitting Added.

> One generally
> requests these changes by using the Nepomuk2::ResourceWatcher.
> Additionally, the Nepomuk2::Resource class internally also uses the
> ResourceWatcher to keep its cache up to date.

Thanks for this information, I wish dbus-monitor could show me which apps are receiving the signal....

This brings me to another possible optimization: 

signal sender=:1.3181 -> dest=(null destination) serial=7191516 path=/resourcewatcher/watch27351; interface=org.kde.nepomuk.ResourceWatcherConnection; member=propertyAdded
   string "nepomuk:/res/40c95b2f-f18c-44d6-ab48-fcb97c905e6d"
   string "http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject"
   array [
      variant          string "Re: KDE/kdelibs/kio/kio"
   ]
signal sender=:1.3181 -> dest=(null destination) serial=7191517 path=/resourcewatcher/watch27351; interface=org.kde.nepomuk.ResourceWatcherConnection; member=propertyChanged
   string "nepomuk:/res/40c95b2f-f18c-44d6-ab48-fcb97c905e6d"
   string "http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject"
   array [
      variant          string "Re: KDE/kdelibs/kio/kio"
   ]
   array [
   ]
signal sender=:1.3181 -> dest=(null destination) serial=7191518 path=/resourcewatcher/watch27399; interface=org.kde.nepomuk.ResourceWatcherConnection; member=propertyAdded
   string "nepomuk:/res/40c95b2f-f18c-44d6-ab48-fcb97c905e6d"
   string "http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject"
   array [
      variant          string "Re: KDE/kdelibs/kio/kio"
   ]
signal sender=:1.3181 -> dest=(null destination) serial=7191519 path=/resourcewatcher/watch27399; interface=org.kde.nepomuk.ResourceWatcherConnection; member=propertyChanged
   string "nepomuk:/res/40c95b2f-f18c-44d6-ab48-fcb97c905e6d"
   string "http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject"
   array [
      variant          string "Re: KDE/kdelibs/kio/kio"
   ]
   array [
   ]

This is the same information, emitted twice, once with path /resourcewatcher/watch27351 and once with path /resourcewatcher/watch27399. This is a bit like emitting a QObject signal twice because there are two
receivers :-)
Well, I suppose this isn't a simple matter, if these two watchers are watching different things, just
with a common intersection which the above happens to fall into. But the common case is probably
multiple watchers with the same parameters; in such a case, are the watcher paths reused?
i.e. if you create two resource watchers to watch the same thing (in the same process or in two different processes),
will they share the same registration (path) on the server side, rather than each have their own?

I think using dbus is fine for notifications, but still, using it efficiently might be better :)

I see nepomukservices using 100% CPU most of the time since I last updated kdepim stuff,
and gdb says it's mostly busy preparing dbus messages to send out.
Ah, I see two issues in qdbusintegrator.cpp, I'll send a separate message to Thiago and you about that.

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