[Nepomuk] Redundant DBus communication

[Vishesh Handa]

On Sun, Jan 13, 2013 at 3:56 PM, David Faure <faure at kde.org> wrote:

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

You're right. We can possibly remove the added and removed signals and
infer that data from the changed signal.


>
> > 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?
>

They'll each have their own. This has mostly been done cause it is really
hard to implement it otherwise.

On the server side we have 3 hash tables which maps the following keys  -
* Resources
* Properties
* Types

to each ResourceWatcher.

Each ResourceWatcher can watch a number of different combinations of all of
these (They conditions are ANDed). Therefore it is just a lot simpler for
each for each ResourceWatcher to listen to their own dbus path, instead of
creating special dbus paths for the intersection of resource/properties and
types.



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

Hmm. That's not good.

But I don't  think it would be simple to change the number of signals being
emitted. One thing that I have been thinking about it the use of
ResourceWatcher inside the Resource class. Though it keeps the cache up to
date, is it really worth it? Maybe we shouldn't do that add a
Resource::reload() function which reloads its contents. The client can
control that manually, if they really require updates.

I think I should run the storage service in callgrind and see what is
actually going on. I've only done that for the file indexer so far, and
that was without any watchers.



> 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
>
>


-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130113/610edc45/attachment-0001.html>