[Kde-pim] Speed of storing large numbers of records, and sizes of akonadiserver and dbus-daemon
Andras Mantia
amantia at kde.org
Mon Feb 27 07:04:29 GMT 2012
Hi,
Shaheed Haque wrote:
> I managed to catch the inital part of the debug output, and I *think*
> this is the command that is fetching all the results:
>
> akonadi_exgal_resource_269 (0x7fdb30030ec0) 35 FETCH 1:* FULLPAYLOAD
> ALLATTR CACHEONLY EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION
> COLLECTIONID FLAGS SIZE DATETIME)
>
> I assume the asterisk is the reason whay all the records are fetched?
> Assuming so, that seems to come from
> ItemFetchJobPrivate::startFetchJob(), which is started from
> ItemSync::doStart(). IIUC, the idea seems to be to fetch the entire
> collection, modify it, and then write the results using
> ItemModifyJob. The key line of code seems to be in
> ItemSync::doStart():
>
> ItemFetchJob* job = new ItemFetchJob( d->mSyncCollection, this );
>
> Now, given that I am signalling my intention to modify only part of
> the collection by calling ItemSync::setIncrementalSyncItems(), how
> about if the above line was changed to moral equivalent of:
>
> ItemFetchJob* job;
> if ( d->mIncremental ) {
> incremenatlItems = d->mRemoteItems + d->mRemovedRemoteItems;
> job = new ItemFetchJob( incrementalItems, this );
> } else {
> job = new ItemFetchJob( d->mSyncCollection, this );
> }
>
> AFAICS, that would be consistent with the definition of
> setIncrementalSyncItems(), and avoid fetching the whole collection.
> Any thoughts?
Where is your code, can you give us a weblink or such? I assume somewhere in
playground, but just point us.
Maybe you didn't set the setItemSynchronizationFetchScope to not fetch the
full payload when something has changed?
Andras
_______________________________________________
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/
More information about the kde-pim
mailing list