Open Bug 1658026 Opened 5 months ago Updated 3 months ago

Thunderbird 78 is really slow to start with Calendar with lots of events

Categories

(Calendar :: General, defect)

Thunderbird 78
defect

Tracking

(thunderbird_esr78+ affected)

Tracking Status
thunderbird_esr78 + affected

People

(Reporter: standard8, Assigned: rnons)

References

(Blocks 4 open bugs, Regression)

Details

(Keywords: perf)

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.

See Also: → 1658032
Keywords: perf
Version: unspecified → Thunderbird 78

Wayne,

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

Regards,

Flags: needinfo?(vseerror)
See Also: → 1649103

(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

Flags: needinfo?(vseerror) → needinfo?(paul)

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

Flags: needinfo?(standard8)
Summary: Thunderbird 78 is really slow to start with Calendar, even when calendars are disabled → Thunderbird 78 is really slow to start with Calendar with lots of events, even when calendars are disabled

(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.

Flags: needinfo?(standard8)
Depends on: 1659558

(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.

See Also: → 1642292

(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.

Flags: needinfo?(paul)
Regressed by: 1546606

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.

Depends on: 1658032
Summary: Thunderbird 78 is really slow to start with Calendar with lots of events, even when calendars are disabled → Thunderbird 78 is really slow to start with Calendar with lots of events

(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.

Blocks: 1642292, 1649103
See Also: 1658032, 1649103, 1642292

(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.

Assignee: nobody → remotenonsense

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.

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