<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jan 13, 2013 at 3:56 PM, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sunday 13 January 2013 15:26:54 Vishesh Handa wrote:<br>
> Hey David<br>
><br>
> This is normal. Some one is asking for the changes, and that is why the all<br>
> those dbus signals are being emitted. We only emit these<br>
> changed/added/removed signals if someone requests them.<br>
<br>
</div>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.<br>
</blockquote><div><br></div><div>You're right. We can possibly remove the added and removed signals and infer that data from the changed signal.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> One generally<br>
> requests these changes by using the Nepomuk2::ResourceWatcher.<br>
> Additionally, the Nepomuk2::Resource class internally also uses the<br>
> ResourceWatcher to keep its cache up to date.<br>
<br>
</div>Thanks for this information, I wish dbus-monitor could show me which apps are receiving the signal....<br>
<br>
This brings me to another possible optimization:<br>
<br>
signal sender=:1.3181 -> dest=(null destination) serial=7191516 path=/resourcewatcher/watch27351; interface=org.kde.nepomuk.ResourceWatcherConnection; member=propertyAdded<br>
string "nepomuk:/res/40c95b2f-f18c-44d6-ab48-fcb97c905e6d"<br>
string "<a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject" target="_blank">http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject</a>"<br>
array [<br>
variant string "Re: KDE/kdelibs/kio/kio"<br>
]<br>
signal sender=:1.3181 -> dest=(null destination) serial=7191517 path=/resourcewatcher/watch27351; interface=org.kde.nepomuk.ResourceWatcherConnection; member=propertyChanged<br>
string "nepomuk:/res/40c95b2f-f18c-44d6-ab48-fcb97c905e6d"<br>
string "<a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject" target="_blank">http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject</a>"<br>
array [<br>
variant string "Re: KDE/kdelibs/kio/kio"<br>
]<br>
array [<br>
]<br>
signal sender=:1.3181 -> dest=(null destination) serial=7191518 path=/resourcewatcher/watch27399; interface=org.kde.nepomuk.ResourceWatcherConnection; member=propertyAdded<br>
string "nepomuk:/res/40c95b2f-f18c-44d6-ab48-fcb97c905e6d"<br>
string "<a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject" target="_blank">http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject</a>"<br>
array [<br>
variant string "Re: KDE/kdelibs/kio/kio"<br>
]<br>
signal sender=:1.3181 -> dest=(null destination) serial=7191519 path=/resourcewatcher/watch27399; interface=org.kde.nepomuk.ResourceWatcherConnection; member=propertyChanged<br>
string "nepomuk:/res/40c95b2f-f18c-44d6-ab48-fcb97c905e6d"<br>
string "<a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject" target="_blank">http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageSubject</a>"<br>
array [<br>
variant string "Re: KDE/kdelibs/kio/kio"<br>
]<br>
array [<br>
]<br>
<br>
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<br>
receivers :-)<br>
Well, I suppose this isn't a simple matter, if these two watchers are watching different things, just<br>
with a common intersection which the above happens to fall into. But the common case is probably<br>
multiple watchers with the same parameters; in such a case, are the watcher paths reused?<br>
i.e. if you create two resource watchers to watch the same thing (in the same process or in two different processes),<br>
will they share the same registration (path) on the server side, rather than each have their own?<br></blockquote><div><br></div><div>They'll each have their own. This has mostly been done cause it is really hard to implement it otherwise. <br>
</div><br><div>On the server side we have 3 hash tables which maps the following keys -<br></div><div>* Resources<br></div><div>* Properties<br></div><div>* Types<br><br></div><div>to each ResourceWatcher.<br><br></div><div>
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.<br>
<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think using dbus is fine for notifications, but still, using it efficiently might be better :)<br>
<br>
I see nepomukservices using 100% CPU most of the time since I last updated kdepim stuff,<br>
and gdb says it's mostly busy preparing dbus messages to send out.<br></blockquote><div><br></div><div>Hmm. That's not good.<br><br></div><div>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.<br>
<br></div><div>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.<br><br></div><div> <br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ah, I see two issues in qdbusintegrator.cpp, I'll send a separate message to Thiago and you about that.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE, in particular KDE Frameworks 5<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br>
</div></div>