On Dec. 8, 2013, 10:28 a.m., Dan Vrátil wrote: > > On the ETM model change, I struggle to believe that Akonadi fetching the > > data then building a model only for us to then scrape the model for the > > data is going to be more efficient than us just loading the data. > > Dan Vrátil wrote: > We don't scrape the model anywhere! The model lives as long as the plugin > lives, which is for the entire application lifetime (in PersonsPluginManager). > > Assuming you use PersonsModel, the full list has been loaded anyway, as > AkonadiAllContacts monitor has been requested, which loads and caches the > whole list in memory. We actually optimize by sharing the contact from the > model between AkonadiAllContacts and AkonadiContact - which means that > requesting AkonadiContact is bit faster, as it does not have to query Akonadi > for the contact, but just looks it up in the model. >
"Assuming you use PersonsModel" That's the point - we can't assume the user will have a personsmodel. For a lot of cases they won't. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114349/#review45341 ----------------------------------------------------------- On Dec. 8, 2013, 2:48 a.m., Dan Vrátil wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/114349/ > ----------------------------------------------------------- > > (Updated Dec. 8, 2013, 2:48 a.m.) > > > Review request for Telepathy. > > > Repository: libkpeople > > > Description > ------- > > Use a single ETM instead of manually fetching all contacts and then > installing a new Akonadi Monitor for each single AkonadiContact. > > ETM (with EntityMimeTypeFilterModel on top) will do the CollectionFetchJobs > and ItemFetchJobs and data handling for us, which only leaves us with > handling of changes, which we do in slots for QAbstractItemModel's > rowsInserted(), rowsRemoved() and dataChanged() signals. This is much better > than having many Akonadi monitors, because for each change notification that > Akonadi server generates, it has to iterate over all registered monitors and > compare the notification against each monitor's filter. With lots of > monitors, this can impact performance of the server. Although the > AkonadiContacts with their Akonadi monitors are created on demand (so there's > none at the beginning), they are not removed (probably cached somewhere in > PersonsModel), so the number of active Akonadi monitors tends to grow - for > instance going through all contacts in PersonViewer will leave you with one > monitor for each contact fed from Akonadi. > > From Akonadi POV, having one properly configured monitor (hidden in ETM) and > working with data via ETM is a better approach. > > > Diffs > ----- > > CMakeLists.txt 889e96d > src/plugins/akonadi/akonadidatasource.h b09edf8 > src/plugins/akonadi/akonadidatasource.cpp 193de78 > > Diff: http://git.reviewboard.kde.org/r/114349/diff/ > > > Testing > ------- > > Going through all contacts in PersonViewer includes all contacts from > Akonadi, and the application uses only one Akonadi Monitor all the time. > > > Thanks, > > Dan Vrátil > >
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
