From 393846f660802d53d6ff6744cea0c1fa05019ba3 Mon Sep 17 00:00:00 2001 From: Christian Mollekopf Date: Sun, 8 Oct 2017 22:10:04 +0200 Subject: Optimized the incremental update case. This brings the incremental closer to a regular query (about 1.5 times as bad instead of 3.5 times). For a comparison look at MailQueryBenchmark::testIncremental() The optimization is built on the assumption that we i.e. get an update with 100 revisions, and thus the optimization applies to the case where we have multiple revisions within that batch that are part of the same reduction. In such a case we can avoid redoing the reduction lookup over and over. --- tests/mailquerybenchmark.cpp | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'tests') diff --git a/tests/mailquerybenchmark.cpp b/tests/mailquerybenchmark.cpp index ca1e026..402f31f 100644 --- a/tests/mailquerybenchmark.cpp +++ b/tests/mailquerybenchmark.cpp @@ -219,11 +219,14 @@ private slots: populateDatabase(count, 10, false, count); time.restart(); - context.mResourceAccess->revisionChanged(2000); + for (int i = 0; i <= 10; i++) { + //Simulate revision updates in steps of 100 + context.mResourceAccess->revisionChanged(1000 + i * 100); + } //We should have 200 items in total in the end. 2000 mails / 10 folders => 200 reduced mails QTRY_COMPARE(added.count(), 200); - //For every email we have to redo the reduction and increase the count, which is a modification. - QTRY_COMPARE(modified.count(), 900); + //We get one modification per thread from the first 100 (1000 mails / 10 folders), everything else is optimized away because we ignore repeated updates to the same thread. + QTRY_COMPARE(modified.count(), 100); std::cout << "Incremental query took " << time.elapsed() << std::endl; std::cout << "added " << added.count() << std::endl; std::cout << "modified " << modified.count() << std::endl; -- cgit v1.2.3