STR

1. Have a profile which has lots of events.
2. Start Thunderbird

Expected Results

Thunderbird opens and is usable within a reasonable time.

Actual Results

Thunderbird opens, the folder pane is displayed, then about 6-7 seconds later, the thread pane and message view is displayed.

If I disable both calendars, then it is usually around 3-5 seconds.

Profiling shows that the majority of this time is due to CalStorageCalendar loading events and from the calendar.

Note: I also tried it with ical.js, and that took about 9-10 seconds.

Here's an extract of startup with the calendars enabled:

https://share.firefox.dev/33BUeNr

From the ChromeUtils.import line, you can see there's lots happening from CalStorageCalendar to create event objects etc.

If I disable both calendars, then it is usually around 3-5 seconds.

I separated this out to bug 1658032.

Wayne,

I believe this bug may be duplicate of Bug 1642292. Have a look perhaps...

Regards,

(In reply to Richard Leger from comment #2)

Wayne,

I believe this bug may be duplicate of Bug 1642292. Have a look perhaps...

Paul is best judge of that

Mark, is it your opinion this issue and bug 1658032 didn't exist in version 78?

There certainly are hundreds? of ChromeUtils.import — resource:///modules/CalAttendee.jsm and ChromeUtils.import — resource:///modules/CalAlarm.jsm

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

Mark, is it your opinion this issue and bug 1658032 didn't exist in version 78?

Do you mean before version 78? I suspect it did exist before 78, but with Calendar never quite updating correctly, and not really working well enough, I never bothered having it enabled. Now with Calendar on by default this is shown up more. Of course, I could just remove the calendars from my profile, but then I wouldn't be testing it...

There certainly are hundreds? of ChromeUtils.import — resource:///modules/CalAttendee.jsm and ChromeUtils.import — resource:///modules/CalAlarm.jsm

Yes, this seems like a general architecture issue, that's likely going to take a bit of work to solve. Bug 1658032 is likely to be the simpler part - don't create objects for things we know aren't going to be required. For this bug, I suspect there's two main things that would help: 1) Find a less expensive way of creating these objects, 2) Move creating these objects off the main thread, and/or out of the startup path. Both are probably non-trivial.

(In reply to Mark Banner (:standard8) from comment #5)

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

There certainly are hundreds? of ChromeUtils.import — resource:///modules/CalAttendee.jsm and ChromeUtils.import — resource:///modules/CalAlarm.jsm

Yes, this seems like a general architecture issue, that's likely going to take a bit of work to solve. Bug 1658032 is likely to be the simpler part - don't create objects for things we know aren't going to be required. For this bug, I suspect there's two main things that would help: 1) Find a less expensive way of creating these objects, 2) Move creating these objects off the main thread, and/or out of the startup path. Both are probably non-trivial.

I've just split out the first comment here to bug 1659558. It does seem to have around a 23% decrease in startup time, so is worth doing. The second item would be the more ideal one to cover, but would also be more work.

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

(In reply to Richard Leger from comment #2)

I believe this bug may be duplicate of Bug 1642292. Have a look perhaps...

Paul is best judge of that

Yes, this looks like the same basic issue(s). (One difference is, see bug 1642292 comment 73, where the reporter there is not using the "offline support" cache, causing additional delay.) Part of the story is that the refactoring work in bug 1546606 slowed down performance for CalDAV calendars relative to 68.

Thanks Mark for looking into this and working on it. This is next on my todo list.

Taking out the "disable calendars" part from the title, since that's bug 1658032.

I thought I'd said this somewhere before, but perhaps not. I think the issues to investigate here are:

• Calendar loads everything on startup, blocking the main thread.
  • We should look at having a defined start point to start loading calendars, e.g. delayedStartup.
• Calendar starts loading before the UI is fully displayed and functional.
• The calendar view is loaded even though it might not be displayed on startup.
  • Firefox has been doing work to delay loading panels and items until they're needed, maybe some of that can be done here?

Obviously we need to not break alarms & events notifications. However if we could ensure that we don't start loading data until after the UI has started, and we move that loading either into a worker or make it so it can happen in the background, then I think that would help a lot. It would potentially cause a slight delay in events and tasks appearing, but that's probably better than the multi-second 'hang' that can happen at the moment.

(In reply to Mark Banner (:standard8) from comment #9)

I thought I'd said this somewhere before, but perhaps not. I think the issues to investigate here are:

• Calendar loads everything on startup, blocking the main thread.
  • We should look at having a defined start point to start loading calendars, e.g. delayedStartup.

This is assuming people do not want to see their calendar first. Maybe a radio button to toggle, like in Windows where you can optimize for speed or for "Best Appearance" or "Best Performance". Here, it could be "Focus speed on calendar launch" or "Focus speed on email launch". Just a thought.

(In reply to Worcester12345 from comment #10)

(In reply to Mark Banner (:standard8) from comment #9)

I thought I'd said this somewhere before, but perhaps not. I think the issues to investigate here are:

• Calendar loads everything on startup, blocking the main thread.
  • We should look at having a defined start point to start loading calendars, e.g. delayedStartup.

This is assuming people do not want to see their calendar first.

Even if they do, we should get the UI up and available first and then load the details.

My view on this is that at startup TB users would most likely read new email first prior calendar, the main first UI visible being the Email view it should be natural to make it load fast and be interactive as soon as possible allowing users to access and load message (including IMAP online as fast as possible) so they can read them. The email folders updating could occur in parallell in a worker process and complete at his own pace without blocking main process.

The calendar loading isn't needed right away and would require each network calendar to be loaded sync anyway which can take some time during which and user can read emails or do something else.

Calendar sync could also occur in a worker so it does not block main process and TB UX, I would even suggest each calendar to load in a separate worker if that is possible or one after another in the order end-user display then.

There is no need to load calendar UI unless it is accessed by end users or TB idle after new message have arrived...

The event/task pane may be active in Email view but may not be required to load right away as calendar may not be loaded yet and could also be updated as the calendar worker sync is processing without hindering the main process...

Also it would be nice for Activity Manager to show progress of loafing of calendar and other items... so when TB is processing we know what is going on at all time... work more or less well for email much less for calendar processing and sync...

Also each calendar could start by loading -3months +1year period first... then lood additional future and historical data in a second stage perhaps... if the loading is done in a worker tbe main UI remain active...

Fixing bug 1642292 may also help acceletate calendar loading... in my case this bug is a major issue for startup perf...

(In reply to Richard Leger from comment #12)

My view on this is that at startup TB users would most likely read new email first prior calendar, the main first UI visible being the Email view it should be natural to make it load fast and be interactive as soon as possible allowing users to access and load message (including IMAP online as fast as possible) so they can read them. The email folders updating could occur in parallell in a worker process and complete at his own pace without blocking main process.

Ideally any network or other big task should be delayed until the UI is up and usable. Not just calendar, email as well. The aim is to get the user into the app as quick as possible with as complete a display as possible, and then do what isn't required for loading in the background.

Fixing bug 1642292 may also help acceletate calendar loading... in my case this bug is a major issue for startup perf...

That bug, and bug 1649103, are really a group of issues, I believe the startup architecture issues I've described here are most likely the main cause of those issues now we've fixed bug 1659558. Other things may have small effects, but I think investigating and fixing how calendar startup happens will have most gains.

(In reply to Mark Banner (:standard8) from comment #13)

(In reply to Richard Leger from comment #12)

Fixing bug 1642292 may also help acceletate calendar loading... in my case this bug is a major issue for startup perf...

That bug, and bug 1649103, are really a group of issues, I believe the startup architecture issues I've described here are most likely the main cause of those issues now we've fixed bug 1659558. Other things may have small effects, but I think investigating and fixing how calendar startup happens will have most gains.

I agree, there are a group issues that impact performance and especially at startup some calendar related, some others not... though distinction needs to be made between issue directly related to startup from issues that are not related but impact startup performance...
Running Telemetry at startup seems also ill advice it could wait for TB to be idle... or be run last!

For example, Bug 1642292 is not in itself a startup issue it is more related to the time it takes to load and process one caldav network calendar with 4000 items... but because calendar loading run in main process and it tends to Not Responding (due to hiccup in processing network response), that causes impact on TB startup performance as all calendars are loaded immediately at startup... and potentially all affected by the same hiccup...

So yes, the modules(only those required)/UI loading shall take precedence over network activities and only load UI that are required as fast as possible - essentially the main Email UI - the calendar UI can wait as not showing by default (except event/task pane possibly)... unless end-user click on the calendar icon...

Then network related processing shall be prioritised perhaps as well - receiving email first - allowing reading of email as soon as possible while loading calendar and email folder updating in parallel...

Hard to say, but it's possible bug 1514666 could help.

Then network related processing shall be prioritised perhaps as well - receiving email first - allowing reading of email as soon as possible while loading calendar and email folder updating in parallel...

This idea will largely be obsoleted by moving parts of Thunderbird and calendar to their own process, ala bug 1646648. So the better goal is to improve small parts of calendar that are currently expensive - like bug 1659558.

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

Then network related processing shall be prioritised perhaps as well - receiving email first - allowing reading of email as soon as possible while loading calendar and email folder updating in parallel...

This idea will largely be obsoleted by moving parts of Thunderbird and calendar to their own process, ala bug 1646648. So the better goal is to improve small parts of calendar that are currently expensive - like bug 1659558.

However, calendar doesn't have it's own process, right? Do we have a bug for that?

Yes bug 1731227.

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

Then network related processing shall be prioritised perhaps as well - receiving email first - allowing reading of email as soon as possible while loading calendar and email folder updating in parallel...

This idea will largely be obsoleted by moving parts of Thunderbird and calendar to their own process, ala bug 1646648. So the better goal is to improve small parts of calendar that are currently expensive - like bug 1659558.

(In reply to Magnus Melin [:mkmelin] from comment #18)

Yes bug 1731227.

So, should this just be WONTFIX?

Moving to a separate process is probably going to help by using less CPU, but the architectural issues I mention in comment 9 may still be there depending on how it is done.

IMO this bug and bug 1731227 should to be looked at together. I believe Calendar is doing lots of unnecessary and expensive work during its startup and shifting that to another process will obviously help, but will mainly just hide the architectural issues.

How is your experence now, with version 102.3.2?

I can't test this due to bug 1794079 (I'll keep my TB in that state until that either gets fixed or gets a patch, in case someone wants some more debugging info).

(In reply to Mark Banner (:standard8) from comment #22)

I can't test this due to bug 1794079 (I'll keep my TB in that state until that either gets fixed or gets a patch, in case someone wants some more debugging info).

bug 1794079 was resolved as of 102.4.0

(In reply to Richard Leger from comment #12)

My view on this is that at startup TB users would most likely read new email first prior calendar, the main first UI visible being the Email view it should be natural to make it load fast and be interactive as soon as possible ...

A typical Monday at work: Fire up Thunderbird, and see what is on my calendar for the day and the week. Then check all emails, in that order.

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

(In reply to Mark Banner (:standard8) from comment #22)

I can't test this due to bug 1794079 (I'll keep my TB in that state until that either gets fixed or gets a patch, in case someone wants some more debugging info).

bug 1794079 was resolved as of 102.4.0

It seems reasonable now. I think there's still more that could be done to help the performance overall (as described in other bugs), but the main issue appears to have gone.