Comment # 2 on bug 52920 from Patrick Ohly (In reply to comment #1) > I installed Sync on my Ubuntu 12.4 (64 bit) laptop and after some research > chose Mobical as my SyncML service. As noted in this thread, Mobical has > changed its name to Everdroid. I set up an account on Everdroid, tested it > on my phone by capturing sms messages to my laptop, then went to sync using > Sync. It coudn't log in. I kept getting "Failed to login. Could there be a > problem with your username or password?" I tried resetting those to no > avail. The Mobical config template in SyncEvolution still works. But Everdroid uses per-device username/password combinations. After logging into their web site, use "Set up my phone", "manual setup", then sync with SyncEvolution using the username and new password shown to you.

I did some benchmarking on the NDIS 166 Tizen IVI reference hardware, using btrfs as the file system storing the data. On that system, a simple "import contacts" takes: time syncevolution --daemon=no --import test/testcases/10000.vcf database=pim-manager-test-dbus-foo backend=evolution-contacts ... real 2m20.431s top shows that the system is partly idle, with evolution-addressbook-factory take most of the time. The limiting factor is the latency for adding contacts one-by-one via D-Bus. time syncevolution --daemon=no --import test/testcases/10000.vcf database=pim-manager-test-dbus-foo backend=evolution-contacts real 2m20.431s The test involved importing, matching and deleting contacts with the "peer" being a local directory. In other words, this focused on EDS and sync engine performance. To run the test, use the modified testpim.py like this: TESTPIM_TEST_SYNC_TESTCASES=test/testcases/10000.vcf testpim.py -v TestContacts.testSync Can be combined with TEST_DBUS_PBAP_PHONE to also test PBAP timing and make the test more realistic. However, the phone must support SyncML for automatic contact push/delete. The test measures the total duration of the SyncPeer() D-Bus method call. Test data is attached. The data for 1000 and 10000 contacts is fairly realistic, while the data for 5000 just uses F0000 till F5000 as names. In theory, this could have an effect on hash data structures, but this did not seem to happen in practice. 1000: import: 32.273505s match: 15.500893s remove: 23.965385s 5000: import: 173.671093s match: 135.620294s remove: 111.923021s 10000: import: 395.876979s match: 563.556571s remove: 227.145546s Import and remove are roughly linear with number of items. Matching is a non-linear operation, essentially an n^2 algorithm (brute-force comparison of old against new data). So the numbers above are as expected. Watching with top during the import phase: %Cpu(s): 45.0 us, 16.1 sy, 0.0 ni, 30.8 id, 3.9 wa, 1.9 hi, 2.4 si, 0.0 st KiB Mem: 3932184 total, 3276808 used, 655376 free, 9072 buffers KiB Swap: 0 total, 0 used, 0 free, 2646056 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3478 pohly 20 0 663248 46416 14404 S 48.54 1.180 0:52.47 syncevo-dbus-he 3448 pohly 20 0 955684 23728 10852 S 28.93 0.603 0:34.14 evolution-addre 3428 pohly 20 0 774276 24448 17464 S 12.30 0.622 0:17.75 syncevo-dbus-se syncevo-dbus-helper does most of the heavy lifting here, while parsing and preparing data for EDS. The ratio between helper and EDS gets worse (= more work in helper) at the end of the phase. There might be some data structure which do not scale well with number of items. During delete: %Cpu(s): 37.5 us, 24.3 sy, 0.0 ni, 27.8 id, 3.1 wa, 3.1 hi, 4.2 si, 0.0 st KiB Mem: 3932184 total, 3668620 used, 263564 free, 9008 buffers KiB Swap: 0 total, 0 used, 0 free, 2937936 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3753 pohly 20 0 947488 27980 10856 S 58.71 0.712 0:41.08 evolution-addre 3785 pohly 20 0 875868 172940 14320 S 18.57 4.398 0:22.55 syncevo-dbus-he 2261 pohly 20 0 25768 3188 1080 S 12.27 0.081 1:53.90 dbus-daemon So here EDS does most of the work. Batched deletes should speed up the phase considerably (see bug #52669). However, deleting is rare. It would be more important to optimize importing and matching. Importing is limited partly by write performance, partly by internal data structures. Batched writing should be implemented first. Matching is a different beast. It remains to be seen where the bottlenecks are and how that can be addressed without breaking the sync engine's architecture.

It would be useful to have something like: RemoveAddressBook That will remove the addressbook synced if available (as RemovePeer do) but keep the peer definition retrievable via GetAllPeers.

Comment # 1 on bug 52920 from Wes Kussmaul I installed Sync on my Ubuntu 12.4 (64 bit) laptop and after some research chose Mobical as my SyncML service. As noted in this thread, Mobical has changed its name to Everdroid. I set up an account on Everdroid, tested it on my phone by capturing sms messages to my laptop, then went to sync using Sync. It coudn't log in. I kept getting "Failed to login. Could there be a problem with your username or password?" I tried resetting those to no avail. wk

Created attachment 79502 [details] Use top_builddir instead of builddir when building syncevo-local-sync builddir isn't available in older automake so use $top_builddir instead. We've done similar things in libvirt to cope with RHEL5. I've only fixed the one occurence relevant to maemo but can fixup the others as well if desired.

Created attachment 79471 [details] Patch to split options Scratchbox's autoreconf chokes on the -vifW. Splitting the options does the trick.

The current PIM Manager API intentionally focused on one unified address book for the entire system. This is a simplification that may be too limited for a more general usage of the PIM Manager. We should implement an API extension that allows managing (creating/deleting) and configuring (sort order, active address books) multiple unified address books.

It is expected that PBAP II will introduce a unique identifier for contacts that is stable across OBEX sessions. We should use that in the PBAP backend to detect new/updated/removed contacts.

Searching could be extended with and/or operations and more complex match terms, like "field X contains/starts-with/ends-with Y". Sorting could be extended to sort ascending and descending and with a list of fields to use for comparison. Need full specification for the desired feature.