On Mon, 2009-12-14 at 15:34 +0000, [email protected] wrote: > During writing the XMLRPC backend I recognised a high number of > readItem operations, at least when using the command line interface: > > 1. A list of the items is generated (listAllItems) > 2. All items are read (n times readItem) > 3. listAllItems is called for synchronisation (listAllItems) > 4. Data is changed (readItem, insertItem, removeItem) > 5. The new of items is read (listAllItems) > 6. All items are read (n times readItem) > > 1+2 as well as 5+6 seem to be the dumping of the database for logging (and > maybe recovery) purposes.
I've already thought about ways to minimize that. It's done that inefficiently at the moment because initializing change tracking and item dumping is invoked via separate APIs at the SyncSource level. Different implementations might need different code for both, so that "fusing" the two steps into one would only work for TrackingSyncSource. > During a normal synchronisation run they are not necessary as far as I > see. > > As I didn't find a way to switch off these steps by configuration, I made > the following patch: Sync property "printChanges=0" removes the "synccompare" invocation. Dumping of items is still done whenever a logdir is enabled, so turning off logging via "logdir=none" disables that. If you want to preserve logging without database dumping, then I'd be happy to merge a patch for it. Your current patch goes in the right direction by overriding the "logdir" handling in SourceList by running it with m_doLogging=false. A more fine grained "dumpDatabases" sync property would just disable dumping in syncPrepare() and printing of changes (which depends on the dumps). See "printChanges" in SyncConfig.h/cpp for an example property that could be cloned. Cmdline.cpp contains tests for config handling which need to be updated when adding or changing properties. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
