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

RESOLVED DUPLICATE of bug 501302

Status

Calendar
Calendar Views
--
major
RESOLVED DUPLICATE of bug 501302
10 years ago
8 years ago

People

(Reporter: Andreas Pflug, Assigned: martinschroeder)

Tracking

({perf})

Details

(Reporter)

Description

10 years ago
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

10 years ago
Andreas, which test calendar with 600 events did you use?
(Reporter)

Comment 2

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

Comment 3

10 years ago
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.
(Reporter)

Comment 5

10 years ago
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.
(Reporter)

Comment 6

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

Updated

10 years ago
Duplicate of this bug: 400272
(Assignee)

Updated

10 years ago
Keywords: perf
OS: Windows XP → All
Hardware: PC → All

Comment 8

9 years ago
(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?
(Assignee)

Comment 9

9 years ago
Investigating again...
Assignee: nobody → mschroeder
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 501302
You need to log in before you can comment on or make changes to this bug.