[Nepomuk] High mutex contention in Nepomuk2::Resource

[Simeon Bird]

>
> True, good point.
>
>> For patch 3, how about the attached two patches instead?
>
> I learned recently that a QReadWriteLock is actually *more* expensive than a
> mutex: it has to lock+unlock an internal mutex in lock(), and again
> lock+unlock in unlock().
> So a QReadWriteLock is only worth it if
> * there are many more read operations than write (this seems to be the case)
> * but also: if the read operation takes long enough. If it's just about
> checking a bool or two, then it's faster to use a single mutex around that,
> than a QReadWriteLock.

Oh, interesting! I had kind of assumed it was doing something clever
with atomic instructions.
In that case I'll revert the ReadWriteLock patch.

> About PATCH 1/5:
> 1) write a one-line summary when doing git commit, you can see why in the
> attached-as-email format for it.

Sure.

> 2) don't forget to switch to DBusConnectionPool, too

Ok.

>
>> +         * As addResource, but if the added resource is the last first one,
>
> The "last first" one? Typo, or am I missing something?

Yes, typo. Sorry. That patch and those functions got reverted anyway...
I found empirically that locking with the rm mutex instead of using
moveToThread was somewhat faster (see last email in this thread, and
final commit in the branch).

>> I pushed a feature branch: feature/resourcemanagercleanup with both
>> these patch series in them. It's on top of KDE/4.10, and your patches
>> are on top of mine. Does it make sense to you? Vishesh, what do you
>> think?
>
> Great, thanks for doing this.
>
> I took a look at all the commits in the branch, and apart from the fact that
> some of them revert some others (could be cleaned up before merging), it all
> looks quite good. I'll test it in kmail now.

Yup, I'll be sure to cleanup the git history before merge. Thanks.

Simeon