Open Bug 569555 Opened 14 years ago Updated 2 years ago

TB with lightning unresponsive at startup, with high CPU usage and cache disabled

Categories

(Calendar :: General, defect)

Lightning 1.0b1
x86
Linux
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: mozilla, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: perf, Whiteboard: [dupme])

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc11 Lightning/1.0b1 Thunderbird/3.0.4 When thunderbird starts it is unresponsive and computes 60% during about a minute until Lightning has loaded all the tasks and events. Reproducible: Always Steps to Reproduce: 1. Install lightning 2. Restart Thunderbird Actual Results: It's rather unresponsive. Even clicking on folders and messages is very slow. Expected Results: It should be snappy, or maybe only block the Lightning UI, but let me browse my mails.
What type of calendar do you use? Do you use the experimental cache feature?
Version: unspecified → Lightning 1.0b1
What do you mean by "what type of calendar"? As far as I know, I don't use the experimental cache, how can I switch it on?
Keywords: perf
I believe I'm seeing this too: TB 3.1.2, Lightning 1.0b2, Linux x86_64 (Ubuntu 10.04). I'm using the Google Calendar provider, and have reproduced consistently with https:// and http:// feeds (I think there was an SSL-related bug a while back similar to this). I'll play with CalDAV tomorrow if you like. Cache is off.
Blocks: 441710
vseerror, I'm not sure if that bug is related. I've just tried playing with the calendar.invitations.autorefresh setting and it appears to have no effect. :(
Hello, I have the same behaviour Thunderbird 3.1.2 lightning 1.0b2 linux x86 (ubuntu 10.04) Regards
How many events are in your calendars and how many of them are recurring? What kind of internet-connection do you have?
I have a semester's worth of timetable information, with 17 items per week that are set up automatically by my University's timetable-gcal bridge. They're not recurring, so this would mean roughly 17×15=235 items. Thunderbird is unresponsive for around two minutes on an Intel Core 2 Duo U7300. I'll try later tonight to see if ethernet gives the same time of unresponsiveness as the dodgy wifi here.
I've got about 80 active items on my task list, plus a certain number of completed tasks as well. My calendar has 15 event this September, and less in the future months. Only one recurring event.
duplicate of bug 412914?
Bug 412914 seems to be about slowness with caching. However in my case, I see slowness _without_ caching.
Is this still the case with Lightning 1.0b5 and Thunderbird 5? There were numerous performance improvements in the Mozilla Platform that may have affected this bug.
It is indeed always the case with Lightning 1.0b5, Thunderbird 5 and Davical. Loading is a little better but still demand a lot of resources because it recalculates all events.
(In reply to Philipp Kewisch [:Fallen] from comment #11) > Is this still the case with Lightning 1.0b5 and Thunderbird 5? There were > numerous performance improvements in the Mozilla Platform that may have > affected this bug. Alain, what are results with tbird 11 or newer ?
Summary: TB with lightning unresponsive at start, with high CPU usage → TB with lightning unresponsive at startup, with high CPU usage and cache disabled
Whiteboard: [closeme 2012-05-01]
This is still an issue with Thunderbird 11.0.1 and Lightning 1.3, although it is no longer quite as bad as before (phase with high CPU usage lasts less longer now). However, it is still noticable that are startup, while Lightning initializes, imap password entry boxes are very unresponsive. IMHO, the whole thing would be less painful if this lightning initialization could run in a separate thread from the GUI thread, so that the GUI could still stay reasonably responsive. Especially, unresponsive password boxes are a pain, because you are left wondering whether keystrokes aren't being sent to another window due to a focus bug, or whatever.
I couldn't get my hands on a good match in getsatisfaction. But https://getsatisfaction.com/mozilla_messaging/topics/thunderbird_11_01_freezing is an example perf issue.
Whiteboard: [closeme 2012-05-01]
I just got the Thunderbird 11.0.1 update (with Lightning 1.3), and the startup became extrememly slow when Lightning is enabled. Upon startup with Lightning enabled, Thunderbird is displayed as a gray window for about 20-25 seconds, before everything appears and works fine. When Lightning is disabled, Thunderbird needs a few seconds at most to start. The previous version started fast despite Lightning being enabled. Ubuntu 11.04
Just upgraded from Ubuntu 10.04 to Xubuntu 12.04 and with the latest Thunderbird 14.0 and Lightning 1.6 the start-up time is about 1 minute before I can work with Thunderbird. Worse still, once in a while I start Thunderbird and the CPU jumps to 100% and stays there forever and Thunderbird never comes back. I have to start it in safe-mode first to download my email from my IMAP server. We are using CalDAV as a calendar server (and my home directory is mounted over NFS). I have two calendars, one that has a recurring event every week. In Ubuntu 10.04 we never had a problem with slowness and freezing.
using thunderbird 15 on ubuntu 12.04 with lightning and most recent Google-Calendar-Provider installed from mozilla causes the entire application (thunderbird) to be unrepsonsive for >5 mins. Have removed all extensions one by one until the troubleshooting process isolates the google-calendar-provider extension as the one that causes this behavior. this behavior was non-existent until the upgrade of thunderbird 15, and the subsequent upgrade of the lightning/google-provider extensions. lightning still works, thunderbird still works, the google-calendar-provider extension does not.
using thunderbird 17.0.2 on WIN XP SR3 with lightning 1.9 causes the whole system becoming unresponsive for more than 2 minutes quite frequently. If lightning is disabled, thunderbird works without any problems. Lightning is connected to 15 different calendars, some of them being connected via HTTP (not HTTPS), others connected via FTP. There are no local calendars. This problem exists more or less since approx. TB 9.
isn't this a duplicate of bug 733039?
(In reply to Roman Brandl from comment #20) > isn't this a duplicate of bug 733039? Bug 733039 is more about slowness during operation, while this one has been mostly about startup. However, they are similar in that both are somewhat ill defined, and no doubt some of the items mentioned there would help this bug.
I started experiencing this exact same behavior after the 45.5.1 update to Thunderbird. When first started and Lightning is enabled, TB is extremely sluggish for at least 20-30 seconds. CPU and RAM usage is high per Task Manager. Disabling different Calendars in Lightning has no effect. The only way I've found to eliminate the problem is to totally disable Lightning. It is definitely Lightning causing the issue as disabling all other addons EXCEPT Lightning and the problem persists. Disable Lightning and the problem disappears.
oh yes... running on Windows 8.1 64 bit, Intel I7-4770 3.4 GHz. CPU usage averages 15-25% during startup.
I used to have this problem with TB and Lightening. For almost a year I was unable to start up TB with Lightning enable ... it would just hang. Then a few months ago it finally started working again. Unfortunately, the problem is back. It appears to have resurface following the upgrade to TB 45.6.0 on Dec 28/2016. I'm running Lightning 4.7.6. I have a feeling that some changes to TB got lost in this last update -- changes that were critical to the Lightning integration. I'm running Windows 10 64-bit on an Intel Core i7-3537U 2 GHz. Though TB becomes non-responsive, it doesn't seem to max out CPU or other resources. CPU, memory and disk utilization all remain steady -- but TB doesn't respond to mouse clicks and shows (Not Responding) in the title bar.
Whiteboard: [dupme]
Alain, do you still see this when using version 60? (that is, if Bug 1240722 - Thunderbird leaks file descriptors - doesn't have impact the testing)
Flags: needinfo?(mozilla)

I have a Thunderbird 60.9.0 running which currently has 1483 open file descriptors.

Flags: needinfo?(mozilla)

Sorry, comment 26 was about "Bug 1240722 - Thunderbird leaks file descriptors".

Now, about this one here: Yes, when starting up thunderbird, there is always a spike in CPU load, and calendar feels sluggish, although it no longer is quite as bad as it used to be.
However, periodically, at random intervals, CPU goes up and lightning feels sluggish (hah!), but it usually goes back to normal (responsive) within a minute or so. However, the main issue with lightning seems to be that heavy processing is performed within the main event loop, rather than in a separate thread, with the result that even a moderate CPU load has an immediate negative impact on UI responsiveness.

I'm on ubuntu 19.10, thunderbird 68.1.2. For several months now (including on ubuntu 19.04) the calendar and tasks have slowed thunderbird right down to a halt, sometimes unresponsive for many minutes. This can be when just opening the calendar window, changing the displayed month or some other selection process. CPU stays at 100% for that process.

My calendar and tasks are all local.

With lightning disabled all is well.

Gary, do you also still see this issue, with 68 or 78 ?

Flags: needinfo?(jgpuckering)

I'm now on ubuntu 20.04, Tbird 68.10. The cause of the delays on my system was that I had a large number of completed tasks. I use many repeating tasks (often weekly or even more frequent) to remind me to do things, and the completed ones accumulated over the years. I went through the whole lot purging completed tasks, and in many cases deleted the task completely and recreating it. I don't get any serious delays any more.

Wayne Mery: I no longer see this issue in 68. I'm on 68.12, but it hasn't been a problem for months now -- maybe not for a few years.

Flags: needinfo?(jgpuckering)

I'm now on ubuntu 20.04, Tbird 68.10. The cause of the delays on my system was that I had a large number of completed tasks. I use many repeating tasks (often weekly or even more frequent) to remind me to do things, and the completed ones accumulated over the years. I went through the whole lot purging completed tasks, and in many cases deleted the task completely and recreating it. I don't get any serious delays any more.

So this purging of cruft and recreation of repeating tasks with newer TB seemed to help in this instance and got me to thinking. How hard would it be to implement a feature akin to "Purge completed task(s) after X Days, Months, Years?"

If someone is already leveraging "Offline Support" (which I assume means caching), this probably doesn't help much. But for those who aren't, is TB just going out and reading a calendar whose cruft may stretch back years or even decades with tens of thousands of old completed events only to spend time churning through them to come to the same conclusion every time TB starts or syncs: yup, these are dead completed tasks, nothing to see here?

I suppose there also exists the crowd who wants to be able to reference some calendar event that happened 10 years ago.

(In reply to Arthur K. [He/Him/His] from comment #32)

I'm now on ubuntu 20.04, Tbird 68.10. The cause of the delays on my system was that I had a large number of completed tasks. I use many repeating tasks (often weekly or even more frequent) to remind me to do things, and the completed ones accumulated over the years. I went through the whole lot purging completed tasks, and in many cases deleted the task completely and recreating it. I don't get any serious delays any more.

So this purging of cruft and recreation of repeating tasks with newer TB seemed to help in this instance and got me to thinking. How hard would it be to implement a feature akin to "Purge completed task(s) after X Days, Months, Years?"

Is that really the solution?
How come TB can handle hundreds of folders and thousands of emails (15GB of data) but crawl under one network calendar of max 2Mo in size with 4000 thousands of items spanning over 10 years (same period the mailbox was used!)?
I think the over all calendar feature may need to be designed in a way it can scale as data increase before thinking how to automatically deleting end-users data... no?

If someone is already leveraging "Offline Support" (which I assume means caching), this probably doesn't help much. But for those who aren't, is TB just going out and reading a calendar whose cruft may stretch back years or even decades with tens of thousands of old completed events only to spend time churning through them to come to the same conclusion every time TB starts or syncs: yup, these are dead completed tasks, nothing to see here?

I suppose there also exists the crowd who wants to be able to reference some calendar event that happened 10 years ago.

Someone may want (or need for regulatory reason) keep that much amount of data or more in their calendar... it should be possible... certainly TB should be able to handle it smoothly...

Severity: normal → S3

Alain,
Does this still reproduce for you?

Flags: needinfo?(mozilla)

(In reply to Wayne Mery (:wsmwk) from comment #34)

Alain,
Does this still reproduce for you?

High CPU usage at start is still an issue, although no longer as bad as it used to be.

Moreover, after several days of running thunderbird, it again gets very slow, and stays slow. Restarting it fixes the issue (i.e. still slow right after restart, but then goes back to normal after a minute or so).

Flags: needinfo?(mozilla)

(In reply to Alain Knaff from comment #35)

(In reply to Wayne Mery (:wsmwk) from comment #34)

Alain,
Does this still reproduce for you?

High CPU usage at start is still an issue, although no longer as bad as it used to be.

Moreover, after several days of running thunderbird, it again gets very slow, and stays slow. Restarting it fixes the issue (i.e. still slow right after restart, but then goes back to normal after a minute or so).

What version are you running now?

(In reply to Arthur K. (he/him) from comment #36)

(In reply to Alain Knaff from comment #35)

(In reply to Wayne Mery (:wsmwk) from comment #34)

Alain,
Does this still reproduce for you?

High CPU usage at start is still an issue, although no longer as bad as it used to be.

Moreover, after several days of running thunderbird, it again gets very slow, and stays slow. Restarting it fixes the issue (i.e. still slow right after restart, but then goes back to normal after a minute or so).

What version are you running now?

102.6.0

You need to log in before you can comment on or make changes to this bug.