420615 - Very slow response with many calendar-month-day-box displayitems: Gecko problem?

Status: RESOLVED DUPLICATE of bug 501302

(Calendar :: Calendar Frontend, defect)

Description

[Andreas Pflug]

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

Comment 1

[Simon Paquet [:sipaq]]

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

Comment 2

[Andreas Pflug]

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

Comment 3

[Bas van den Bosch]

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

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

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

Comment 5

[Andreas Pflug]

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.

Comment 6

[Andreas Pflug]

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

Comment 8

[Wayne Mery (:wsmwk)]

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

Comment 9

[Martin Schröder [:mschroeder]]

Investigating again...