[Kolab-devel] Analysis of large calendar performance hit

[Stephan Buys]

The fastest code is code thats never executed :-)

The reason TNEF is slow is probably because it is harder to parse,
iCalendar is an easy to parse text format.

IMHO the best solution here would be to only load the calendars that
are necesarry. Ie. dont do unnecesarry work. Even if you can squeeze TNEF the
calendar loading down to 10 seconds, what happens if you have 5000 calendar
entries?

As far as I know you can do intelligent searches in Cyrus as well as indexing, 
maybe this is something to investigate? The IMAP protocol might be very handy
here.

Regards,
Stephan

On Tuesday 22 July 2003 10:52, Arend van Beelen jr. wrote:
> Martin Konold wrote:
> > Currently readiong tnef is not optimized for speed at all.
> > You may expect some
> > improvements with regards to tnef reading speed in the
> > future.
> >
> > Nevertheless I am interested in the speed of native icals.
> > Can you make a test
> > with real 1000 ical calendar entries? Do you measure the
> > same performance problem?
>
> OK, I imported the iCalendar that was exported by Lotus
> Organizer into KOrganizer. That was the same file we
> initially imported with Outlook as well. So now I got two
> versions of the calendar, one with TNEF entries and one
> with libkcal entries. The libkcal version is faster, but
> still slow. Here are the times (both are averages of 3
> tries):
> libkcal: 19 seconds with 1085 entries.
> TNEF: 98 seconds with 1003 entries.
>
> (I knew the TNEF version was slow, but _that_ slow...)
>
> The system I tested on was a Pentium 4, 1.7GHz with 256MB
> memory.
>
> --
> Arend van Beelen jr.
> http://www.liacs.nl/~dvbeelen
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at intevation.org
> https://kroupware.org/mailman/listinfo/kolab-devel

-- 
Stephan  Buys
Technical Director
Code Fusion cc.
Tel: +27 11 391 1412
Mobile: +27 83 294 1876
Email: s.buys at codefusion.co.za