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

[Till Adam]

On Friday 07 July 2006 12:47, Bernhard Reiter wrote:
> 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.

I agree.

> > 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?

I talked to both Reinhold and Cornelius here in Trysil and we agreed 
that this (C) is a bit regression-risky but worth a try.

> > 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)?

I'll probably give it a try over the next few days, and then should be 
able to assess the risk better.

-- 
Till Adam -- till at kdab.net, adam at kde.org
Klarälvdalens Datakonsult AB, Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20060707/f3ace8d1/attachment.sig>