4:56 a.m.
https://bugs.freedesktop.org/show_bug.cgi?id=64838
Priority: medium
Bug ID: 64838
CC: syncevolution-issues(a)syncevolution.org
Assignee: syncevolution-issues(a)syncevolution.org
Summary: PBAP: enhance performance
Severity: normal
Classification: Unclassified
OS: All
Reporter: patrick.ohly(a)gmx.de
Hardware: Other
Status: NEW
Version: 1.3.99.3
Component: SyncEvolution
Depends on: 52669
Product: SyncEvolution
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.