[Kde-pim] Review Request 119418: LIST: Non-Recursive listing
Christian Mollekopf
chrigi_1 at fastmail.fm
Sat Jul 26 21:14:25 BST 2014
> On July 26, 2014, 2:18 p.m., Dan Vrátil wrote:
> > Looks ok, but there seems to be a problem with memory. Running the collectionsync benchmark you wrote, collections are crated just fine, but once LIST begins, memory usage of akonadiserver grows into gigabytes.
Hmm, weird. I can't reproduce the memory problems. Even with 100k collections akonadiserver remained stable around ~70M and the db used slightly less.
On a side note, it seems I get a lot worse performance with your collectionsync than you reported.
Creating 100k collections with your collectionsync patch and the LIST patch applied takes ~580, and 10k with the same patches ~60s (It's great that it seems to grow pretty linear).
Without the LIST patch 10k collections take ~90s, so at least performance improved.
Anyways, no idea how you run into those memory problems, but if you get the perfomance you claimed in the collectionsync review request something else might be fishy.
- Christian
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119418/#review63198
-----------------------------------------------------------
On July 24, 2014, 6:55 p.m., Christian Mollekopf wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119418/
> -----------------------------------------------------------
>
> (Updated July 24, 2014, 6:55 p.m.)
>
>
> Review request for Akonadi.
>
>
> Repository: akonadi
>
>
> Description
> -------
>
> CollectonReferenceTest: Fixed the tests after fixing the reference manager
>
> This test couldn't work because the referenced state is reset after
> each scenario. I adapated the test now accordingly.
>
> LIST: Non-recursive listing
>
> Instead of recursively query for children,
> we query for a list of all collections we're interested in,
> and then assemble a tree.
>
> This potentially results in a small overhead with few collections,
> but should scale much better when we have many collections while most
> are getting filtered by the initial query (i.e. disabled collections).
>
> Additionally this patch ensures enabled collections that are nested in
> a disabled collection are correctly found.
>
> Share DbInitializer for other tests and make use in listhandlertest.
>
> use dbinitializer
>
> remove the collections manually since sqlite doesn't deal with constraints.
>
>
> Diffs
> -----
>
> server/src/handler/list.h 56401b3164e5035518d63ed39e5a048481808560
> server/src/handler/list.cpp b891d10d2ceb63482a4453695dc38ee625b8c768
> server/tests/unittest/CMakeLists.txt b9744d93a3b0cb9e895141c10ddaf2703f12acf0
> server/tests/unittest/collectionreferencetest.cpp 808227f9771a33dc1c77d960160770ca919ea2fd
> server/tests/unittest/dbinitializer.h PRE-CREATION
> server/tests/unittest/dbinitializer.cpp PRE-CREATION
> server/tests/unittest/listhandlertest.cpp b25b6a85538cec786c09a2f2cc629b2be5c82fec
>
> Diff: https://git.reviewboard.kde.org/r/119418/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Christian Mollekopf
>
>
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list