User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Build Identifier: Lightning 0.8pre 20080229919 on TB 2.0.0.12 Follow up on 392418, 403922 et al I wanted to trace down the slow performance with many remote calendars and events. While I didn't examine the storage part, I found that even simple local calendars show very poor performance. I traced this down to calendar/content/calendar-month-view.xml#calendar-month-day-box. Commenting out this.dayitems.insertBefore(box, before) in relayout() will cut down the time to fractions of a second, i.e. the problem is not creating and filling so many calendar-month-day-box-items, but adding them to the vbox. This appears as a Gecko problem to me. Reproducible: Always Steps to Reproduce: 1.On a fresh calendar installation, create an additional calendar, import this data to the new calendar: BEGIN:VCALENDAR BEGIN:VEVENT CREATED:20080302T200132Z LAST-MODIFIED:20080302T200210Z DTSTAMP:20080302T200132Z UID:9da9644e-9657-4aa2-a2eb-82d1d1cfd000 SUMMARY:Testevent RRULE:FREQ=DAILY;UNTIL=20080410T200000Z;INTERVAL=1 DTSTART;TZID=/mozilla.org/20071231_1/Europe/Berlin:20080210T220000 DTEND;TZID=/mozilla.org/20071231_1/Europe/Berlin:20080228T230000 END:VEVENT END:VCALENDAR. 2. select month view for March 2008 3. toggle the calendar display of your first (still empty) calendar, with the second test calendar displaying the test data. Actual Results: On a 3GHz machine, switching will take 6 seconds with 600 events displayed, 100 % CPU on one kernel. Expected Results: I'd expect a month view with 50 events per day to display more or less instantly. (say 0.2 sec, so I'd need a 300GHz machine :-)

Andreas, which test calendar with 600 events did you use?

See ics above. Alternatively, the storage.sdb used is at http://www.pse-consulting.de/mozilla/storage.db

Is it possible to call the vbox just once, prepopulating the order of the events per day in memory?

I tried caching the item boxes some time ago, but that didn't really help.

There are several places that can be optimized, esp. mOperationListener.onOperationComplete (knowing that mDateBoxes is ordered, it can be accessed by index instead of using findBoxesForItem). Since the current implementation is iterating growing lists over and over again, its time consumption grows exponentially (something like 40 % in this case). With less events, the vbox items issue clearly dominates, scaling proportionally. dayitems.insertBefore is called once per day per event; no way to cut this down unless the rendering is changed radically.

The issue is currently under discussion in mozilla.dev.tech.dom with Boris Zbarsky (look for "nsGenericElement::InsertBefore performance"), please assist if you can.

(In reply to comment #6) > The issue is currently under discussion in mozilla.dev.tech.dom with Boris > Zbarsky (look for "nsGenericElement::InsertBefore performance"), please assist > if you can. other than "http://developer.mozilla.org/en/docs/Writing_Efficient_CSS seems to cover it. The one thing that jumped out at me was the use of the ' ' combinator. That's usually a bad idea performance-wise.", is writing some code the only other takeaway from that discussion?

Investigating again...