Open Bug 362987 Opened 18 years ago Updated 3 years ago

Large calendars with many recurring items slow down the app

Categories

(Calendar :: Provider: Local Storage, defect)

Product:
Calendar
Component:
Provider: Local Storage
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

People

(Reporter: mingodad, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: perf)

User-Agent: Opera/9.01 (Windows NT 5.0; U; en) Build Identifier: SunBird/0.41a Whe populates with several recurrent events like using the http://ical.mac.com/rainbowfly/FLY-RADIO32SCHEDULE.ics it becomes unusable, too slow, I did some research and found that in the function getItems from local storage if we insert a this.mDB.beginTransaction() at the begining and a this.mDB.commitTransaction() at the end we can reduce the time spent to half but it is still to slow, when moving fron one day to another it seeks and proccess 200 recurrent records to show only 6 events in the calendar and other six in the top list filtered by today events. It seems that the actual algorithm is not apropriate because it get worst when the number of recurrencies grow. For comparison only I downloaded Personal calendar from www.calendarscope.com the shareware download and importesd the same calendar from Fly Radio and it's performance is astonishing, if we can solve this problem the claendar will be usable, because right know it's only a proof of concept, a good one but not usable. Reproducible: Always Steps to Reproduce: 1.import a calendar from http://ical.mac.com/rainbowfly/FLY-RADIO32SCHEDULE.ics 2.try to use it and navigate through it 3.comment a line on calStorageCalendar.js and see the difference, there is the slowdown for each (var evitem in resultItems) { /////// count += handleResultItem(evitem.item, evitem.flags, Ci.calIEvent); if (checkCount()) return; } Actual Results: A lot slow, wait a bit, it works but take a long time to show and to move from day to day. Expected Results: Navigate smootly. Navigate smootly.
I can confirm it with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070114 Calendar/0.6a1 but it also looks like duplicate of bug 355454
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [qa discussion needed]
Joey, you might want to take a look at this w.r.t. your other performance fixes. Damian, we decided that we do not have enough information at this time as to whether or not 355454 is a dupe of this bug -- they seem to be in two different providers.
Keywords: perf
Whiteboard: [qa discussion needed]
(In reply to comment #2) > Joey, you might want to take a look at this w.r.t. your other performance > fixes. Yeah, the cache I submitted helps a lot here. There are still some optimizations for the actual recurrence expansion that I've discussed elsewhere, but the cache should reduce the time these calls take by about 80%. See bug 366177.
Flags: wanted-calendar0.8+
Summary: Problem that slow down calendar when there is several recurrent events → Large calendars with many recurring items slow down the app
I've posted some results of a Venkman profiling session in the developer newsgroup. You can find those here: http://groups.google.com/group/mozilla.dev.apps.calendar/msg/20c4823deb717199 http://groups.google.com/group/mozilla.dev.apps.calendar/msg/a316e5a3539351a3
The calendar you used in that test doesn't contain any RRULE, so no recurring events. Sine this bug is about recurring items, it's not relevant here.
This is less a comment than a whine by a user: Sunbird 0.7 ( Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8pre) Gecko/20071023 Sunbird/0.7 )on my Dell Inspiron 1100 running XP sp2 is abysmally slow. I have a large calendar with lots of recurring events. It will take 20 to 45 seconds to perform some simple operations like changing from one week to another. During this time the program will use 93-98% of the processor. Thanks for your efforts, folks!
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Flags: wanted-calendar0.8- → wanted-calendar0.9+
My experience on Sunbird 0.7 , on a somewhat old machine (Win2K, 512MB, 900Mhz) was exactly as described in Comment #36, even though I have only about 60 recurring events (670 events in all). Simon wrote (Comment #7): "Not going to happen for 0.8" I had assumed that meant that work on this bug was not going to happen in 0.8 . But now I wonder if what he meant was that this slowness wasn't going to happen. (Which did you mean, Simon?) In any case, *something* sure happened! The release notes for Sunbird 0.8 include: > Sunbird contains several performance fixes, > which should improve working with larger calendar files I don't know the details of what was fixed, but the result for me has been dramatic. The "simple operations" that were "abysmally slow" are now, for me, taking 2-4 seconds. Sunbird's usability has improved enormously. I wonder how this looks for very large calendars, and I suggest that those concerned with this slowness might want to weigh in on whether it is still a problem. Of course, if there was something in the works to make response even snappier and more scalable, that's great. But perhaps the priority should be re-evaluated. Thanks for the great work!
Whoops, I meant Comment #6, not 36
Flags: wanted-calendar1.0+
Flags: wanted-calendar0.9+
Flags: blocking-calendar1.0?
This sounds very similar to my problem... It becomes very much worse with multiple iCals on a shared network drive. https://bugzilla.mozilla.org/show_bug.cgi?id=462283 Is it a combination of excessive screen redrawing and inefficient caching and loading of shared remote iCals ? This is really important to fix, all the good features in TB are sadly worth nothing if our PC's become unusably slow. Shared iCals over local networks that have fast local machine "smart" caches are critical to TB's future success. Any ideas/comments from programmers? Does anybody know if this problem is being addressed in Lightning/TB 3.0 integration? Can I help?
I just tried Calendar scope from http://www.calendarscope.com/index.html?src=cs-main&version=4.0r, shared iCals over a network drive... Super fast, virtually no delay over the LAN. I may be purchasing Calendar Scope until Lightning/TB 3.0 is fixed to be as fast. This hurts as I love TB and lightning, but this bizarre slowness is absolutely crippling. ( sad ) Good Bye dear friends
OS: Windows 2000 → All
Hardware: x86 → All
How do the fixes for bug 390036 work?
Unfortunately this won't make 1.0 unless someone steps up for it. I originally wanted to respond here, but due to the number of comments here I decided to file a new bug for it. Please leave the bug clean for technical discussion, we all agree that performance improvements are needed. The bug I filed is bug 498968. This bug talks about a few ideas how we can improve performance of the storage provider, especially regarding recurring events.
Flags: blocking-calendar1.0? → blocking-calendar1.0-
Ok, so I tried to move the parsing of events into threads, which now actually works when everything is marked as threadsafe. I couldn't notice an enourmous performance win, the UI is still blocked. Maybe in combination with bug 501302 it works better.
Actually I take that back. I was surprised how error-free things were until I noticed that my C++ files didn't compile and it was using the old version! "JS Objects cannot be shared across threads"...well so much for using chrome workers at all, this will get worse when we use js-ctypes.
Severity: normal → major
Blocks: 719381

Geoff,

Only comment 0 is relevant in this bug - is this covered in another bug report?

(In reply to Domingo Alvarez from comment #0)

...
Whe populates with several recurrent events like using the
http://ical.mac.com/rainbowfly/FLY-RADIO32SCHEDULE.ics it becomes unusable,
too slow, I did some research and found that in the function getItems from
local storage if we insert a this.mDB.beginTransaction() at the begining and
a this.mDB.commitTransaction() at the end we can reduce the time spent to
half but it is still to slow, when moving fron one day to another it seeks
and proccess 200 recurrent records to show only 6 events in the calendar and
other six in the top list filtered by today events.

It seems that the actual algorithm is not apropriate because it get worst
when the number of recurrencies grow.

For comparison only I downloaded Personal calendar from
www.calendarscope.com the shareware download and importesd the same calendar
from Fly Radio and it's performance is astonishing, if we can solve this
problem the claendar will be usable, because right know it's only a proof of
concept, a good one but not usable.

Reproducible: Always

Steps to Reproduce:
1.import a calendar from
http://ical.mac.com/rainbowfly/FLY-RADIO32SCHEDULE.ics
2.try to use it and navigate through it
3.comment a line on calStorageCalendar.js and see the difference, there is
the slowdown
for each (var evitem in resultItems) {
/////// count += handleResultItem(evitem.item, evitem.flags, Ci.calIEvent);
if (checkCount())
return;
}

Part of this code was added in bug 366177 ?

Flags: needinfo?(geoff)

Well, obviously, if you completely ignore recurring items and don't display them anywhere the program is going to get faster. That's what commenting the line mentioned does.

However, in my experience there is a lot of unnecessary calculation done, because any recurring event that no longer happens is still being calculated fully. I'm currently considering a number of options on this front.

Flags: needinfo?(geoff)
You need to log in before you can comment on or make changes to this bug.