1513202 - Thunderbird v slow to start (18 mins) with Lightning enabled

Status: RESOLVED WORKSFORME

(Calendar :: General, defect)

Description

[Ken]

Attachment: memory-report.json.gz

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

Start TB (which has 4 IMAP email a/c and 4 CalDAV calendars). Monitor with Task Manager. 


Actual results:

Takes around 18 minutes for intermittent 'not responding' msg to go, and for CPU to drop from ~17% to <1%. Once this has happened, TB/Lightning behave normally.
Problem goes away if I disable Lightning. Problem also goes away with Lightning enabled, but with the 4 calendars disabled: startup reduced to 17s and no 'not responding' msgs. If I then tick the calendars one at a time at 1s intervals, they all load within another 15s. So total of 32s instead of 18 minutes to arrive at stable state.


Expected results:

Mailboxes and calendars should all have opened within reasonable time (around 20s?) with all 4 calendars enabled.

Windows 10 (1803) 8GB. Dell AIO with I7.

I noticed that task manager never showed memory above 350MB.

It's usable if I remember to untick the calendars before closing TB, then tick them on next use. (But I forget, and it used not to be like this!) Not sure if this troubleshooting memory report is useful. It was created after an 18-min startup.

Comment 1

[Arthur K. (he/him)]

Sounds like a dupe of bug 1509739? This is with TB 60.x ESR or beta?

Comment 2

[Arthur K. (he/him)]

Ken,

By the way, which TB version are you on now and is it still happening?

Comment 3

[Ken]

V60.7.2 (32bit). Yes it is still happening. But what I haven't tried is to start with a fresh profile to see if that fixes it, which I think it has for others.
I will report back here.

Comment 4

[Arthur K. (he/him)]

(In reply to Ken from comment #3)

V60.7.2 (32bit). Yes it is still happening. But what I haven't tried is to start with a fresh profile to see if that fixes it, which I think it has for others.
I will report back here.

Thanks for being willing to give that a try. Do report back if it works or not.

Comment 5

[Ken]

I couldn't quite bring myself to start with a new profile, (but I will if you ask me to!)
Instead, I deleted (not just unticked) all the calendars and deleted the data in calendar_data folder. No change.
But what I did see in the console, both before and after the calendar delete is this:

While creating services from category 'profile-after-change', could not create service for entry 'calendar-backend-loader', contract ID 'service,@mozilla.org/calendar/backend-loader;1'
Use of Mutation Events is deprecated. Use MutationObserver instead. calendar-widgets.xml:512:20
NS_ERROR_FAILURE: Couldn't decrypt string crypto-SDR.js:179
NS_ERROR_FAILURE: Couldn't decrypt string crypto-SDR.js:179
NS_ERROR_FAILURE: Couldn't decrypt string crypto-SDR.js:179

Not sure if it's relevant but it does mention calendar.

Comment 6

[Ken]

I decided to bite the bullet and start with a fresh profile, adding 1 item at a time, and testing.

I now have 4 IMAP mail accounts and 4 CalDAV calendars working. It takes about 20s to become reponsive after starting, which is fully acceptable.
Of course, I have no means of telling if doing this would have fixed the problem with earlier versions, but I am glad it has gone away.

(btw, the error:
While creating services from category 'profile-after-change', could not create service for entry 'calendar-backend-loader', contract ID 'service,@mozilla.org/calendar/backend-loader;1'
is still present in the console.)

Thanks for your interest.

Comment 7

[Geoff Lankow (:darktrojan)]

While creating services from category 'profile-after-change', could not create service for entry 'calendar-backend-loader', contract ID 'service,@mozilla.org/calendar/backend-loader;1'

That's very odd. Have your tried removing Thunderbird completely (not your profiles obviously) and reinstalling it from a fresh download?

Comment 8

[Arthur K. (he/him)]

(In reply to Ken from comment #6)

I decided to bite the bullet and start with a fresh profile, adding 1 item at a time, and testing.

I now have 4 IMAP mail accounts and 4 CalDAV calendars working. It takes about 20s to become reponsive after starting, which is fully acceptable.
Of course, I have no means of telling if doing this would have fixed the problem with earlier versions, but I am glad it has gone away.

(btw, the error:
While creating services from category 'profile-after-change', could not create service for entry 'calendar-backend-loader', contract ID 'service,@mozilla.org/calendar/backend-loader;1'
is still present in the console.)

Thanks for your interest.

Ken,

Thanks for the report. I am leaning towards saying that something wonky in the old profile(s) must have been culprit to the slowness issue and the new profile doesn't have the issue. As someone whose profile hasn't been refreshed in the better part of 5+ years, I know how tough it is to have to start from scratch and get all the settings and configs back to the way you've had them for years. Not fun. But thanks for helping out and and, it seems, somewhat confirming that a profile refresh helps with this slowness issue.

The devs will have to do some digging into the "profile-after-change" issue to see what that's all about though. Thankfully, TB 60.8.0 is around the corner and 68.0 is not too far off and I think 68.0 will help with some of these performance issues, especially the x64 version. I have an old Latitude E6500 with an SSD that I use at work and the beta of 68.0 x64 runs fairly well as compared to 60.x x86 versions. I myself have three IMAP accounts and two calendars and it takes about 6-10 seconds from cold start for TB to become usable.

All that being said, can we close this bug now as WORKSFORME and say that a profile refresh helped resolve it?

Comment 9

[Ken]

In response to #7, I tried uninstalling TB, rebooting PC, re-installing TB60.7.2 (GB). PC is Dell AIO 64-bit W10-1903.
Console still shows: could not create service for entry 'calendar-backend-loader',

In response to #8
The calendars contain entries dating back to 2010 with entries created using iPad, iPhone, and Communigate (the mail/CalDAV server) via its web interface, so who knows what sort of incompatible data these may have introduced. TB console notes a whole bunch of things which don't seem to affect anything, and the entries show in the calendar OK, eg:

Parsing failed for parts of the item (while this is considered to be a minor issue, we continue processing the item):
BEGIN:VCALENDAR
PRODID:CommuniGate Pro 6.2.9
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20190710T004532Z
UID:9a729834-aec4-42b2-8641-ca4fc467c3e8
SEQUENCE:0
SUMMARY:Rosita Vigil
DTSTART:20120611T050000Z
DTEND:20120611T080000Z
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
LAST-MODIFIED:20120611T030200Z
CREATED:20120610T003933Z
PRIORITY:5
X-MOZ-GENERATION:1
X-MOZ-LASTACK:20120611T030044Z
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT2H
DESCRIPTION:Default Mozilla Description
X-LIC-ERROR;X-LIC-ERRORTYPE=PROPERTY-PARSE-ERROR:Parse error in property n
ame: LAST-TRIGGERED
END:VALARM
END:VEVENT
END:VCALENDAR

But starting with a new profile and manually creating accounts etc means that it WORKSFORME

Thanks!

Comment 10

[Arthur K. (he/him)]

Thanks Ken! Resolving as WORKSFORME. Noting it's likely the same issue as bug 1509739, bug 1522990 and likely bug 1502923.