[Kde-pim] More about KRecursiveFilterProxyModel

[David Faure]

The problem with the superfluous dataChanged() signals emitted by 
KRecursiveFilterProxyModel (see e.g. 
https://git.reviewboard.kde.org/r/122227/)

is that they trigger many calls to "reload()" in the FavoritesCollectionModel.
Try adding a kDebug in there and using kmail, it's horrendous (and it's a real 
time sink, any time I interrupt kmail with gdb, it's in that code - even 
before my changes to KRecursiveFilterProxyModel, but possibly even more so now 
that it handles dataChanged more correctly).

Somehow it's made even worse by the stack of proxies used in kmail, because in 
the debug output I see this:
imagine you have nested folders like A / B / C / D, if the number of unread 
emails in D changes, then dataChanged signals are received by 
FavoritesCollectionModel like this: D, C, B, A, C, B, A, B, A, A.
It's as if there were two KRecursiveFilterProxyModel in the stack....
(I didn't check whether that was the case).


So, I spent some time this weekend trying to fix KRecursiveFilterProxyModel so 
that it doesn't emit superfluous signals. Since there's no 
dataAboutToBeChanged in Qt, the only way to know if dataChanged actually 
changed the filtering status of an index, is to have a cache, and compare 
before/after.
I implemented all this, and it works great AFAICS, see 
https://git.reviewboard.kde.org/r/122252/

Every call to Akonadi::EntityTreeModelPrivate::monitoredCollectionChanged, 
which triggers one dataChanged signal in the ETM, still leads to 4 calls to 
Akonadi::FavoriteCollectionsModel::Private::reload for some reason,
but at least it's not 4+3+2+1=10 calls, anymore.

Apart from reviewing my two RB patches, I'd welcome any input on whether:

* ETM's monitoredCollectionChanged really needs to be emitted so often
(it seems any FetchJob emits it, even if nothing changed?)

* FavoriteCollectionsModel really needs to do so much work on dataChanged 
(Christian, I can't help but wonder if your changes a year ago to this class, 
for performance reasons, actually made it worse - I keep seeing kmail spending 
time there)

* Maybe FavoriteCollectionsModel could sit on top of ETM (or some intermediate 
model that just filters for folders) rather than sitting on top of so many 
proxies, so that it gets called less often? (the fact that any QSFPM turns any 
source dataChanged into a layoutChanged really doesn't help with performance 
in models sitting on top...)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/