[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