Re: [SyncEvolution] Faster synchronisations on TrackingSyncSource-based backends?
On Mon, 2009-12-14 at 15:34 +0000, knipp(a)m-otion.com 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.