400272 - slow work

Status: RESOLVED DUPLICATE of bug 420615

(Calendar :: General, defect)

Description

[Timur]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; ru; rv:1.8.1.8pre) Gecko/20071016 Sunbird/0.7

i have many tasks in the calendar (about 100). so, when i change view from day2month and vice versa it took about 2 min to complete the action. actually when i make any action in this calendar it works real slow. HW: DL580 HP 4 Xeon Dual 2.8 Ghz processors and 3 GB ECC memory DDR2. And in task manager there is onlu 80 MB usage of RAM by Sunbird and only one of proc is used for 12%, other are free.

Reproducible: Always

Steps to Reproduce:
1.Make 100 task
2.try to change view
3.add a new task
Actual Results:  
works slow

Expected Results:  
works fast

Comment 1

[Andreas Pflug]

I can confirm this problem.
0.8pre (20080225-en) accessing davical server, using a slow 600MHz machine (enough memory), caldav and ics give similar results.

Memory consumption after fresh start:
one remote calendar with two events ->21MB
same, with remote calendar with 200 events -> 34MB
same, but with local calendar -> 24MB

Toggling the small calendar will take 8 seconds if the second calendar is remote, and 4 seconds if local, and 12 seconds if the 200 events are distributed over 10 calendars. Caching works (no access logged), but doesn't change performance noticeably. Startup time is 2 minutes or so.

Toggle duration seems independent of day/week/month view, scales with number of events (and reciprocal to CPU frequency, 100 % cpu on a single core)

Since I need 12 calendars (total 1000 events per month), performance is far from acceptable. 

Comment 2

[Simon Paquet [:sipaq]]

Please only set the wanted0.8? flag as the wanted0.8+ flag is reserved for release drivers.

Comment 3

[Bas van den Bosch]

I think we can dupe this bug against 420615 or 412914. The description in comment 0 is a general slowness. 

Comment 4

[Martin Schröder [:mschroeder]]

(In reply to comment #3)
> I think we can dupe this bug against 420615 or 412914. The description in
> comment 0 is a general slowness. 

Agreed. This report is very general, so it is better to dupe against bug 420615.