Closed Bug 198142 Opened 22 years ago Closed 18 years ago

900 events in Calendar renders it almost unable to save a new event!

Categories

(Calendar :: General, defect)

Product:
Calendar
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: btallman, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 I have around 900 events imported into my Calendar and it is almost UNUSABLE. I have seen commments from users implying that this isn't a problem and that I should purge my calendar. Not so as I, and many others, use my calendar as a way to remember past events. There isn't even a way to purge the events! As 1000s of items doesn't kill the IMAP client, I have to believe that it can be done. Reproducible: Always Steps to Reproduce: 1. 2. 3.
We will need a great number of events to test this. Does somebody have a event generator or know where we can find such a large file ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I will "sterilize" my calendar file and attach it... Give me a few days...
*** Bug 209690 has been marked as a duplicate of this bug. ***
New contact from mikep@oeone.com to mostafah@oeone.com Filter on string OttawaMBA to get rid of these messages. Sorry for the spam.
Assignee: mikep → mostafah
Confirming that Calendar is near-unusable with 900+ events. (Downloaded today; Help->About Calendar doesn't seem to do anything?) RH Linux 7.1 with 2.4.14 kernel. Calendar alerts freeze Mozilla for hours. Selecting 'All Events' in the top drop-down is a Bad Thing that hangs my machine at 100% CPU for several minutes (dual Pentium 800+MHz). Adding new event does seem to be possible - takes 5-6 seconds, as does deletion. This is with 'Currently Selected Day' selected. Do you still need need a large number of events for the testing?
Has the situation improved after the checkins for bug 262620 and bug 265457?
(In reply to comment #6) > Has the situation improved after the checkins for bug 262620 and bug 265457? My user also has this same type of problem. It can take up to 38 seconds to add a new event while deleting takes around 5-8 seconds. I don't have an exact count of the events, but he averages 307 events per day and has events from Jan 2004 to 2007. (the future dates are not as filled yet as the past/current however) System is a dual P3 1.133 server with 2gigs of ram and the .ics file is on a localy avail linux server (100mb connection) and his ics file is about 348k.
But which version does he use? Does it have the checkins for said bugs?
*** Bug 209977 has been marked as a duplicate of this bug. ***
*** Bug 281773 has been marked as a duplicate of this bug. ***
*** Bug 255561 has been marked as a duplicate of this bug. ***
*** Bug 244337 has been marked as a duplicate of this bug. ***
QA Contact: gurganbl → general
Current Sunbird trunk is slow, but just about usable. I have 1,200 or so entries. 25 seconds to add a simple event 45 seconds to delete the event This on a 1.8GHz Pentium 4, Linux. 768MB RAM.
OS: Windows XP → All
Version: unspecified → Trunk
Things still pretty bad; with my build from yesterday CVS, Linux/x86. o 1m 15s - from cmdline startup to usable window o 30s - add an event o 40s - delete an event o 20s - go to today (when today not already visible) As my default calendar is SDB-based it's not immediately obvious how many events I now have. My storage.sdb file is 374KB, if that helps. I'd be happy to do some profiling tests, if anyone has any suggestions?
re the timings given in comment 14: o publishing the entire calendar and then grepping the ics file shows I have 1325 events. o hardware as before: 1.8GHz Pentium 4, Linux. 768MB RAM. Otherwise idle system.
(In reply to comment #14) > Things still pretty bad; with my build from yesterday CVS, Linux/x86. > > o 1m 15s - from cmdline startup to usable window > > o 30s - add an event > > o 40s - delete an event > > o 20s - go to today (when today not already visible) > > As my default calendar is SDB-based it's not immediately obvious how many > events I now have. My storage.sdb file is 374KB, if that helps. > > I'd be happy to do some profiling tests, if anyone has any suggestions? You might try re-profiling today, since I think brettw checked in some performance-related storage changes yesterday. Also, you could try using Venkman w/Lightning and/or jprof to get more specific profile-data. There are also a couple of other bugs open on performance stuff; you may wish to search for those.
Seems to have got a little worse, unfortunately: builds: 0213 0219 (seconds) add event 30 45 delete event 40 80 go to today 20 30 1325 events in local SDB file. 1.8GHz Pentium 4, Linux. 768MB RAM. Otherwise idle system (I checked). The only other relevant perf bugs I see is bug 262209, which appears to be a dup of this one, although it's not been so marked. I've not done any moz-related profiling before; are there any docs out there I where I can start, please? thanks much.
(In reply to comment #17) > I've not done any moz-related profiling before; are there any docs out there I > where I can start, please? thanks much. > My suggestion would be to start with trying to get a handle on using Venkman. The Venkman tutorial has a section on using it for profiling http://www.svendtofte.com/code/learning_venkman/advanced.php#profiling . Also, thanks to gekacheka, you can find a Sunbird-compatible version of Venkman here: http://www.geocities.com/gekacheka/venkman/index.html The difficult part here is going to be trying to understand the code-flow that happens when events are add/modified/deleted. Since you're only concerned with the storage provider, that simplifies things somewhat. The key is to try to identify which areas of the code represent bottlenecks that are eating up time. (I'm writing this basic structure from memory, so it might be somewhat off.) (1) Clicking OK in the event dialog first builds a calIEvent item in calendar-event-dialog.js::saveDialog (2) This then passes into the onNewEvent callback function that was created in calendar-item-editing.js::createEventWithDialog (3) This function dives into the storage provider http://lxr.mozilla.org/mozilla/source/calendar/providers/storage/calStorageCalendar.js#348 which as you can see quickly goes to adoptItem. (4) Finally, adoptItem ends by notifying all of its observers of the new item with observeAddItem. My strong suspicion is that the observer calls will represent the vast majority of the time spent. If I'm wrong and the problem lies elsewhere, ignore what follows. The problem with observers: Observers, at this stage, are pretty dumb. Some of them, when they hear about the new item that was added, are actually going to go off and ask every calendar for a whole new list of events! Tracking down cases where this happens needlessly is probably where we can make the biggest wins. To help here: Search lxr for instances of onAddItem. Add dumps so you know when they are being called, and the time they spend before they finish. Another good search to do is to look at lxr calls to getItems and add dump()s in these to spot when they're called. In general, we want to refrain from calling this function as much as possible. Right now we do it way too often. The problem with this bug is that it's a catch-all for a bunch of problems. Please file new bugs with isolated cases of places where substantial time is spent. The devs can then help you decide whether these are necessary evils, or can be improved.
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Didn't we get the add/delete numbers way down by tweaking the unifinder?
yes, things are *hugely* better now, thanks.
Resolving as fixed based off of the checkin in bug 314291. I have already filed some other bugs to deal with other slow spots in large calendars, specifically startup and moving views.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
one other thing that is still very slow is refresh of remote WebDAV calendars; do we have a bug for that, or should I log one?
subscribe (remote calendars) calendars: 3 all events: ~2000 time to load : 12s CPU: not good - up to 100% even when events was visible (rendering?) memory usage: ~100MB it's not good, however I can create and save new events but... the issue was about importing, so I tried to import more than 800 events, new profile, waited more than five minutes... Sunbird was growing and growing (memory) and still used up to 100% of CPU I had to kill process... conclusion: if I can subscribe up to 2000 event within 10 seconds I can expect that can import 200 even faster, right? the problem is that events were improted because after restart I could see them, but Sunbird did not response so I had to kill process Joey, did you fix importing or subscribing? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060901 Calendar/0.3a2+ and calendar for testing (downloaded and imported): http://ical.mac.com/tsmallwood/Celebrity.ics
Status: RESOLVED → REOPENED
Flags: blocking0.3?
Resolution: FIXED → ---
(In reply to comment #24) > Joey, did you fix importing or subscribing? I fixed the bug as described. With many, many events in your calendar, it used to be very slow to create/modify/delete events. These actions are now fast. I argue that you are now describing bug 187177, and that this bug should remain as fixed.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → FIXED
(In reply to comment #25) > With many, many events in your calendar, it used > to be very slow to create/modify/delete events. These actions are now fast. agree, thanks for details -> VERIFIED
Status: RESOLVED → VERIFIED
Flags: blocking0.3?
You need to log in before you can comment on or make changes to this bug.