<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jan 13, 2013 at 6:26 PM, Vishesh Handa <span dir="ltr"><<a href="mailto:me@vhanda.in" target="_blank">me@vhanda.in</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Sun, Jan 13, 2013 at 5:57 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Sunday 13 January 2013 17:12:15 Vishesh Handa wrote:<br>
> You're right. We can possibly remove the added and removed signals and<br>
> infer that data from the changed signal.<br>
<br>
</div>Won't this require expensive lookups on the receiver side?<br>
(If not, then I agree.)<br>
<br>
The alternative would be to emit added without emitting changed right away --<br>
but I don't know the current design (= what happens with these signals).<br></blockquote><div><br></div></div><div>I'll put up a patch tomorrow.<br></div></div></div></div></blockquote><div><br></div><div>Fixed. Still testing it a bit more before pushing. <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> They'll each have their own. This has mostly been done cause it is really<br>
> hard to implement it otherwise.<br>
><br>
> On the server side we have 3 hash tables which maps the following keys -<br>
> * Resources<br>
> * Properties<br>
> * Types<br>
><br>
> to each ResourceWatcher.<br>
<br>
</div>Yes, and I wonder if it happens often that the exact same set of keys is<br>
requested by the same code in multiple applications.<br>
In kdepim, I suspect this might happen? Or maybe I don't really understand the<br>
context. It's worth checking, at least.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>> Each ResourceWatcher can watch a number of different combinations of all of<br>
> these (They conditions are ANDed). Therefore it is just a lot simpler for<br>
> each for each ResourceWatcher to listen to their own dbus path, instead of<br>
> creating special dbus paths for the intersection of resource/properties and<br>
> types.<br>
<br>
</div>Right. I'm not suggesting intersections, but equality tests.<br></blockquote></div><div><br><div><br></div><div>I've grepped the entire kdepimlibs, kdepim and kdepim-runtime for ResourceWatcher. I fond the following -<br>
<br>vlap:~/kde/src/kdepim $ a ResourceWatcher<br>messagelist/storagemodel.cpp<br>39:#include <Nepomuk2/ResourceWatcher><br>122: Nepomuk2::ResourceWatcher *watcher = new Nepomuk2::ResourceWatcher(this);<br><br>mailcommon/filter/filtermanager.cpp<br>
30:#include <Nepomuk2/ResourceWatcher><br>122: Nepomuk2::ResourceWatcher *watcher = new Nepomuk2::ResourceWatcher(this);<br><br>kmail/tagactionmanager.cpp<br>39:#include <nepomuk2/resourcewatcher.h><br>62: Nepomuk2::ResourceWatcher* watcher = new Nepomuk2::ResourceWatcher(this);<br>
<br></div>The
FilterManager and TagActionManager are actually both just watching for
the type nao:Tag. They could indeed be merged together. This would have
be done on the server side. I'm not sure exactly how to do it, but it is
possible. I'll try.<br> <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If the same very very old email of mine is watched by more than one process,<br>
I'm pretty sure it's not related to my own actions, but to some generic<br>
watching, which would be the same in multiple PIM processes.<br></blockquote><div><br></div></div><div>I'm not sure who is watching for emails. It would be nice to know. The simplest way would be to add debug statements in the storage service (resourcewatchermanager.cpp). I just looked at the code, and it can easily be optimized quite a bit as well.<br>
<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> > I think using dbus is fine for notifications, but still, using it<br>
> > efficiently might be better :)<br>
> ><br>
> > I see nepomukservices using 100% CPU most of the time since I last updated<br>
> > kdepim stuff,<br>
> > and gdb says it's mostly busy preparing dbus messages to send out.<br>
><br>
> Hmm. That's not good.<br>
<br>
</div>That's mostly due to a bug in qdbusintegrator.cpp though (no cleanup of old<br>
dbus objects in the tree, cf my mail to Thiago and you).<br></blockquote><div><br></div></div><div>Lets see if something can be done in time for 4.10 <br><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> But I don't think it would be simple to change the number of signals being<br>
> emitted. One thing that I have been thinking about it the use of<br>
> ResourceWatcher inside the Resource class. Though it keeps the cache up to<br>
> date, is it really worth it? Maybe we shouldn't do that add a<br>
> Resource::reload() function which reloads its contents. The client can<br>
> control that manually, if they really require updates.<br>
<br>
</div>The client wouldn't know when to call reload(). </blockquote><div><br></div></div><div>They could always create their own ResourceWatcher!<br> <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
However, if there are use<br>
cases where updates are unlikely or unimportant, maybe a<br>
Resource::setAutoUpdating(false) would be good to have.<br></blockquote><div><br></div></div><div>This seems like a better approach. But that would be adding a new API and I'm not sure if I should be asking for another exception from the Release Team. I'm sure they are quite tired of me. Though most of the applications don't really need live updates.<br>
<br></div><div>Not sure what to do.<br><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But I really wonder who could possibly be watching my very old email; this<br>
must be some generic "watch all emails" thing? I guess I should add debug<br>
output in ResourceWatcher, but 1) it's used very very often in kmail, and 2)<br>
nepomuk resource URIs don't tell me much.<br>
<div><br></div></blockquote><div><br></div></div><div>Right. Then it is definitely coming from the Resource class.<br><br></div><div>Try commenting out the details of the Nepomuk2::ResourceManagerPrivate::addToWatcher function.<br>
<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
> I think I should run the storage service in callgrind and see what is<br>
> actually going on. I've only done that for the file indexer so far, and<br>
> that was without any watchers.<br>
<br>
</div>Well, profiling at the low-level is kind of what I just did.<br>
<br>
What would be more useful IMHO would be a higher-level picture (who is<br>
watching what, and for what purpose), to detect "stupid behavior" at the<br>
semantic (no pun intended) level.<br></blockquote><div><br></div></div><div>Yes. That would be nice.<br><br></div><div>We need to do a rewrite of the entire NepomukShell and make it actually return useful information like this. The storage service does know about all of this "higer-level" stuff.<br>
<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
David, who just realized his dbus service IDs are now up to :1.114565 --<br>
something is registering/deregistering very very often to dbus... this didn't<br>
use to be the case, hmm. Maybe threads coming and going, with their per-thread<br>
dbus-connection...<br>
<div><div><br>
--<br>
David Faure, <a href="mailto:faure@kde.org" target="_blank">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></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br>
</div></div>