[Kolab-devel] Improving Kontact's performance with large Kolab calendars

[Bernhard Reiter]

Am Montag, 3. Juli 2006 09:21 schrieb Till Adam:
> some users have run into performance problems with very large calendars
> using Kontact (https://intevation.de/roundup/kolab/issue1118), and we
> need to decide on the best ways to remedy those problems both short
> term and long term. Below is a summary of the possible options, the way
> I see them. Please comment, so we can reach consensus on what is the
> best course of action.

Till, thanks for the good sumary!

> Mid- to short-term approaches:

To me we should find a mid-and-short-term solution to keep KDE 3.x
and Kolab going at coporate users with many calenders.

> A) Improve 1) b) by switching from QXml to libxml or similar. Since QXml
> is known to be slow, this should give a decent speed boost. I would
> imagine in the area of 10 to 20 percent, but that's pure guesswork.
> Hard to judge how much work this would be, I'm guessing a few man-days.
>
> B) Avoid 1) a), b) and c) by putting an additional CachedResource, which
> stores the calendar info in its own cache and does uid-mapping, between
> KOrganizer and the KMail cache. This trades speed for space, since a
> full copy of the calendar on disk is made. Additional benefit is that
> it would allow the calendar to load without a running KMail. On disk
> cache would be ical, which is faster to parse, so the speed would be on
> par with a large ical file calendar. Somewhat of a hack, and a
> non-trival amount of work.

Calender information usually are small. There is the exception of attachments
which supposetly _should_ work.
With many calenders, the size requirement might be a drawback,
I also have a bad feeling about the icalendar format used for the cache
and about the information regarding folders and access control status.
Would all information be saved in that new cache?

>
> C) Improve 2) by increasing the granularity of notifications, thereby
> hopefully avoiding full reloads in most cases. This would mean an
> extension of the resources framework, and a difficult to judge amount
> of work in KOrganizer's view layer. This approach might bring corner
> case regressions, since currently a lot of things rely on the full
> calendar being reparsed in various situations.
>
>
> Since I believe 2) to be the actual usability problem, meaning that
> users should be ok with a slow-ish initial load, provided normal
> operations afterwards are fast, I would tend towards C) as the most
> promising option. It's fairly intrusive on the KOrganizer side, though,
> so I'd especially like Reinhold's input on this. 

I agree.
Any reaction from Reinhold already?
Should be crosspost this discussion to some other KDE lists as well?

> A) would be fighting 
> symptoms, and might not gain as much, and B) probably appeals to me
> because it decouples KOrganizer and KMail better, which is not
> something that is of much concern to most of our users.

Yep.
Any idea on the effort of implementing C)?

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1310 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20060707/1e5c5510/attachment.p7s>