462283 - Lightning Very Slow using shared iCalendars on local network drive

Status: RESOLVED DUPLICATE of bug 501302

(Calendar :: Lightning Only, defect)

Description

[Paul Smith]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Thunderbird version 2.0.0.17 (20080914)   with Lightning V 0.9

We recently exported our Lightning calendars from our local PC's and private profiles to a shared "Calendar" directory on our shared network drive. This was to allow us to share our iCal calendars, and post tasks to each other.

Consequently, with the first start up of TB with network iCals  ( 5 small calendars <300k with tasks and events )it is getting really slow, up to a minute and very sluggish navigation. Reloading Calendars virtual freezes the screen, causing user impatience and crashing. it's quite bad, becoming unusuable.

Reproducible: Always

Steps to Reproduce:
1.Create 5 iCals of about 300k each on a network drive.
2.Open all of them in Lightning
3.
Actual Results:  
Starting Thunderbird and Lightning is very slow. Navigation and reload is very very slow. Switching windows to TB/Lightning refresh is very slow.

Expected Results:  
Quick navigation, quick window refresh, quick reload of small iCals. ( 300k is tiny!)

I also noticed that when moving the mouse on the TB window on thelocal computer, the CPU usage peaks up to 70%. What is it doing? Other apps such as Open Office rarely go above 10%

Local PC's are Windows XP, 2.4Ghz CPU, 1Gb Ram...plenty for this app.
Network drive is on a P4 3.0Ghz HT WXP, 1Gb ram on a 100Mb Etherent.

All other Apps absolutely screaming fast, including massive Open Office spreadsheets and databases, and graphics files.

Comment 1

[Paul Smith]

I have done some more research...

I tried caching the 5 iCals, and it took even longer to load TB. (right click on each calendar in the left pane, options, select cache ) I noticed that a cache.sqlite file is created in a "calendar-data" directory in the user profile. That takes about 2 minutes to do. This looks like the "fast" cache file... but it is very slow :(, something just isn't right.

I have taken off the cache option, and deleted the cache.sqlite file.

I also noticed a "backupData" directory full of iCalendar Files that look like "calBackupData_1225078370875_edit-1" What are these, and how many will Lightning produce?

Comment 2

[neotek]

I am experiencing the same issues with iCal files stored on local hard drives. We use locally stored iCals which are synchronised with other applications across the network using 3rd party software.

TB has been set up to access the local iCal files and now we have very slow reloads of the calendars causing TB to freeze until the reload is complete.

We have 7 iCals that TB opens of which the largest is only 158Kb.

Comment 3

[Paul Smith]

I did a test with Calendarscope with exactly the same iCal files, and it was almost instant with multiple shared calendar access on our LAN, I have to say it was very impressive. Something must be very sick in Lightning. Maybe sqlite used in Lightning is not good with multiuser access or maybe it's just some bad screen refresh code?

http://www.calendarscope.com/index.html?src=cs-main&version=4.0r

Then there is always Google Calendar in the web browser, but resource tasking costs $50 per year ( unless you are not for profit/education )

Comment 4

[Paul Smith]

I had a very slight improvement by defragging the file server  and replacing the wireless card with ethernet cable.

iCals were not very fragmented but the email sdb had >300 fragments, so i suspect this was more related to the email upload speed.

I don't think this is the answer, only a desperate attempt : (

Comment 5

[Henry Bakker]

We were very excited when we started using the Lightning extension for Thunderbird. Now, a half year later Lightning is slowing down Thunderbird. Starting Thunderbird takes about 20 to 30 seconds. When Lightning refreshes the calendars, the systems hangs for a couple of seconds. Turning off the Lightning extension resolves the problem. But that is not the solution I think...

The pc's are fast enough (Pentium 4 3GHz, 1GB RAM, Windows XP Pro), and also our fileserver can't be the bottleneck. Besides, if I move the ICS-files from the fileserver to the local desktop, Lightning is also very very very SLOOOOOW!!

This is really a bad bug in Lightning. We don't want to use Outlook...

Comment 6

[Bas van den Bosch]

This issue is known in Lightning 0.9 and tehre have been some fixes to the old branch. However, in TB 3.0b2 with the latest Lightning Trunk this should be solved. Could you retest with the latest Lightning?

related bugs: bug 481033 bug 187177 bug 350342 bug 462280 etc etc

As for comment 3: it's probably the screen-related: bug 420615

Comment 7

[pieter.monsieurs]

I tested with the version 3.0.1 of TB and Lightning version 1.0b1, and the problem still persists.
I have to calendars in the same setup as mentioned above, one for personal items (around 50 kb) and one for work related items (about 2Mb). When I start TB, I have to wait for 30 seconds before I can do anything. The first calendar loads very quick, the second one causes the slow start-up. 
Maybe related to this problem: the "large" calendar also crashes very often when I try to dismiss calendar items.

Comment 8

[a_geek]

I have the same problem with even smaller calendar file(s). I have two mini calendars on a webdav server (~6 and ~13k), and now imported the FOSDEM 2010 calendar from this file (File->Open):
http://fosdem.org/schedule/ical (~ 180k).

Now Thunderbird 3.0.1 and Lightning 1.0b1 under Debian Testing/i386 are slow. Switching on the calendar takes about one second, but switching it off takes 40 seconds, during which one of my 3GHz-cores on my 945 is pegged to 100%. Disk activity is light during this period, though, it's purely a CPU problem.

Comment 9

[Rene Balvers]

We have the same eperiences. Why don't we add a basic MySQL or preferably Postgres interface to the Calender?

Comment 10

[a_geek]

I, for one, would hate to see another MySQL dependency. Having this pluggable, and/or being able to write to LDAP, or a REST service, would be great, though.

Comment 11

[Philipp Kewisch [:Fallen][📱📆]]

The performance bottleneck is currently in the calendar views. We are aware of the problem and are working on fixes. For now I'd like to mark this duplicate of bug 501302. We will file new bugs if performance is still mediocre afterward.