> > 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 _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
