[Kde-pim] Review Request: Proposal to speed up first sync
Bertjan Broeksema
b.broeksema at home.nl
Fri May 29 16:27:42 BST 2009
> On 2009-05-29 05:52:36, Douglas Harms wrote:
> > This approach is essentially what I was thinking about and in fact had planned on working on a patch today - you beat me to it!! I'll run some tests, but right now I think it looks good. Thanks!!
> >
> > (I had also thought about using start date instead of description as the hash. My reasoning is that quite a few entries could have the same description, but there would be only a few entries on a day which might reduce the search time a bit. But then I'm not sure if all entries have a date, which would mess things up. Anyway, just a thought/suggestion/whatever.)
>
> Bertjan Broeksema wrote:
> A start date might do for calendar but not for contacts to name one. This patch is generic and works for all Akonadi conduits. Btw I wonder if we can do much better than a ~1 minute for ~6000 records. Still I think that with 6000 records the average number of entries with the same description is quite likely to go in the direction of 1. Even if it's a bit higher the algorithm will keep at about O(n) I think, but you may correct me if I'm wrong on that.
>
> As a side node, this patch also contains the code of Douglas his patch (http://reviewboard.kde.org/r/531/)
>
> Douglas Harms wrote:
> Using the description field does indeed seem more generic and applicable to all conduits, and is thus a better choice.
>
> I tested your patch and it does indeed work VERY nicely! I think you can commit it.
>
> (This patch also minimizes or nullifies the need for tickling the palm since it's unlikely that the connection will timeout now. Oh well, I suppose tickling won't hurt.)
>
> (BTW, how long did akonadi take to process your 6000 records? As I've mentioned on kde-pim, akonadi_ical_resource takes over 3 hours to process the 5600 records inserted by kpilot. I don't think it's me, but it would be interesting to know if others are having similar issues.)
>
> (This patch also minimizes or nullifies the need for tickling the palm since it's unlikely that the connection will timeout now. Oh well, I suppose tickling won't hurt.)
It won't hurt and it also contains the progress code which I *like a lot*.
> (BTW, how long did akonadi take to process your 6000 records? As I've mentioned on kde-pim, akonadi_ical_resource takes over 3 hours to process the 5600 records
> inserted by kpilot. I don't think it's me, but it would be interesting to know if others are having similar issues.)
http://markmail.org/message/v7wbwo6c52jszhxc
- Bertjan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/776/#review1223
-----------------------------------------------------------
On 2009-05-29 02:42:08, Bertjan Broeksema wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/776/
> -----------------------------------------------------------
>
> (Updated 2009-05-29 02:42:08)
>
>
> Review request for KDE PIM, Douglas Harms and Jason Kasper.
>
>
> Summary
> -------
>
> Use a QSet during first sync to reduce the amount of time for looking up
> matches. Each time a match is found the id of the matched pc record is added to
> the set.
>
> The next time findMatch is called the it will again iterate over all pcrecords
> but if the pcrecord id is in the set allready the equal method will not be called.
>
> I did not test it yet, this patch is just to show the idea.
>
>
> Diffs
> -----
>
> trunk/KDE/kdepim/kpilot/conduits/todo/todohhrecord.h 974238
> trunk/KDE/kdepim/kpilot/conduits/todo/todoakonadirecord.h 974238
> trunk/KDE/kdepim/kpilot/conduits/todo/todoakonadirecord.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/keyringconduit/keyringhhrecord.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/keyringconduit/keyringhhrecord.h 974238
> trunk/KDE/kdepim/kpilot/conduits/contacts/contactshhrecord.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/testrecord.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/testrecordconduit.h 974238
> trunk/KDE/kdepim/kpilot/conduits/calendar/calendarakonadirecord.h 974238
> trunk/KDE/kdepim/kpilot/conduits/calendar/calendarakonadirecord.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/calendar/calendarhhrecord.h 974238
> trunk/KDE/kdepim/kpilot/conduits/calendar/calendarhhrecord.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/contacts/contactsakonadirecord.h 974238
> trunk/KDE/kdepim/kpilot/conduits/contacts/contactsakonadirecord.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/contacts/contactshhrecord.h 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/rcfirstsynctest.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/testdataproxy.h 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/testdataproxy.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/testhhdataproxy.h 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/testhhdataproxy.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/testhhrecord.h 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/testhhrecord.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/base/tests/testrecord.h 974238
> trunk/KDE/kdepim/kpilot/conduits/base/recordconduit.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/base/recordconduit.h 974238
> trunk/KDE/kdepim/kpilot/conduits/base/record.h 974238
> trunk/KDE/kdepim/kpilot/conduits/base/hhdataproxy.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/base/dataproxy.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/base/dataproxy.h 974238
> trunk/KDE/kdepim/kpilot/conduits/akonadibase/akonadidataproxy.cc 974238
> trunk/KDE/kdepim/kpilot/conduits/todo/todohhrecord.cc 974238
>
> Diff: http://reviewboard.kde.org/r/776/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Bertjan
>
>
_______________________________________________
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