perf+hotspot shows that this is a horrible algorithm:
http://www.davidfaure.fr/kde/perf_hotspot_itemsync.png
I ported the code to the std::move (the algorithm)
Details
Details
- Reviewers
dvratil - Commits
- R165:033667a64ff0: ItemSync: speed up by not using takeFirst().
Added a benchmark to itemsynctest.
Before:
RESULT : ItemsyncTest::testFullSyncManyItems():
368,935,368.19 CPU cycles per iteration (total: 36,893,536,820, iterations: 100)After:
RESULT : ItemsyncTest::testFullSyncManyItems():
349,899,659.49 CPU cycles per iteration (total: 34,989,965,949, iterations: 100)
=> 5% faster (for the whole of ItemSync, which runs much more than this piece of code)Went down to 346 million after https://commits.kde.org/kcoreaddons/42e1d6e8e7bf7f2738fbe15778b23a84c104e8a8
(Qt + Akonadi built in release-with-debug; KF5 in debug, but not much KF5 code being run here)
Diff Detail
Diff Detail
- Repository
- R165 Akonadi
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Oh and I notice: The patch doesn't include info about the state after - did you measure it and verify that this is indeed faster? I.e. is the move actually happening and everything faster now?
A benchmark would be optimal in such scenarios, of course.