User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091103 SUSE/3.5.5-2.2 Firefox/3.5.5 FirePHP/0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.6pre) Gecko/20091121 Calendar/1.0pre I've talking about a bit in bug #501622 I've create a test server that can be used to debug / test sunbird in it's actual 1.0pre version. I've placed 8600 schedules events in ten different schedules on a period running from 01.01.2008 until now. It's a real db used, but I've just encrypted the data. You can check how to connect and use it at http://caldav-test.ioda.net/ (There a preconfigured sunbird profile that can be used with sunbird 1.0pre version) Reproducible: Always Steps to Reproduce: 1.Connect to the test server 2. Use the preconfigured sunbird profile 3. Measure the time to render the first complete view of 10 schedules. 4. Actual Results: Tests made on customer site ( in which the server is Gigabit connected and is a amd opteron 6 cores with 16Gb ram and bunch of sas 15000 disk) give the following result in terms of rendering (the time you wait before able to use calendars ) Machine / Time Pentium4 3.0Ghz 1Gb RAM XP32-SP3 : 3m30 Pentium4 DualCore 3.2Ghz 2Go Ram : 3m10 Amd X2 5000+ 2.6Ghz 2Gb Ram : 2m15 Amd X2BE 2400 4Gb Ram Linux 32bits pae : 2m30 Centrino DualCore T7700 2.4Ghz 4Gb ram linux 32bits : 1m45 In the meantime, the server finish pushing schedule in 20 seconds Expected Results: Load & render schedule really quickly in < 30 secondes even on quiet old machines. The only test I've not yet made is to check the rendering time for local file calendar. (I will post a complementary note about it) I have to change parameter in configuration to not refresh schedule below 5 minutes. If you put it a 1minute interval, start never ends on slow machines. To be able to work a bit ( after being patient we have desactivated the task view the alarm view, and the search view ). If you activated them then sunbird reask the server for each view and start flickering around during x times the first render time. What I would is trying to get sunbird of one the best pim software we can use and be proud of. So if there's any way I can help you to improve it make a sign. In next message I will put a link to a screencast of what's happen.

You can find a screencast about the rendering effect Take on a DualCore pentium 4 3.2Ghz windows 2003 serveur with 2Ghz ram. http://linux.ioda.net/sunbird/sunbird-1.0pre_rendering-10-schedules_pc-windows2003-dualcore-3ghz.ogv

An update to say : after sunbird 1.0-b1 nothing better ( chance nothing worse, but how can this could be happen :-) ) As said in presentation, you can simply reproduce it using the live caldav-test made for you. http://caldav-test.ioda.net

I've given the server a short test and I can confirm. I haven't had time to find out where the bottleneck is.

It seems to me after seeing how the render is done that the path is the following. The renderer view start it's jobs, immediately after receiving the first schedule data. In background the caldav retriever gets more data. transmit them to the view renderer which start sorting events, and render them ... And so on ... I think (but I'm not a mozilla coder xul so I explain it in pseudo-algo ) it should have to work following this path. During data retrieving (and all data retrieving, think to alarms etc.) viewer do nothing just display a message waiting data refreshing ... When all data are here, trigger one time sort, after the sort, retrieve only the need data time frame to display (day view, week view, ... ). So viewer rendering has a little to do, just what is needed then display this in one pass. I can manage some sort of retribution to make this working, as it's customer mandat.

Right now calendars are by default in the uncached mode, which downloads and parses the data it needs, just in time. This is of course not the ideal solution, so we once introduced the cached calendar. Unfortunately our storage calendar isn't fast enough since it uses old, synchronous APIs and saves the calendar data in a non-ideal way. This should be improved in bug 498968. Also, we currently have bug 479867 which makes the cache totally unusable for more than one calendar. When this is fixed, we might be able to switch the cache on by default, which means we can do very quick retrievals and then feed the view data directly off the local cache. I admit its quite a long way, but its the only sensible way to go. I do hope we can improve performance for the next beta, but I'm not sure how much of this path we can go.

Another thing I forgot (thanks mvl!), the biggest performance bottleneck right now is probably rather the rendering of the boxes themselves. So even if we do have the faster storage, drawing the boxes will not be any faster. bug 501302 tries to simplify the view boxes, which gave me a (afair) 30% performance win with many boxes, but the calendar views are very complex which is causing the patch to do unexpected things. Also there is bug 460030, which should also improve box drawing quite a bit.

As beta2 is coming can we expect some new speed somewhere ? on http://caldav-test.ioda.net I added some new collections, one is archives containning 11500 events. If you made a test there a big difference between using caldav schedules and local schedule. (even substracting the download time ). Try to get all collection (can be easily downloaded ) and build them as local schedules. Close sunbird and measure performances between the two providers ... Did you see like me a BIG difference ? I'm thinking there another trouble inside the caldav component.

I'm going to take this off the blocker1.0 list in favor of bug 462277 and bug 501302. We should re-test performance after those bugs are fixed.

As you want. For having an access to caldav-test just drop me an email