1623111 - Disable background calendar services when all calendars are disabled

Status: RESOLVED WONTFIX

(Calendar :: General, task)

Description

[Paul Morris [:pmorris]]

For users who are not using calendars. For example, the alarms service should be disabled.

Comment 1

[Paul Morris [:pmorris]]

Beyond the alarms service, I'm looking into exactly what should be disabled (and re-enabled). Possibilities include:

• the calendar manager (which has a load and unload function)
• midnight update timer
• calendar command controller (has unload function)
• calendar window prefs observers
• todaypane (has unload function)
• invitations manager
• others I'm missing?

Philipp, do you have suggestions or insights on this? Beyond the specifics, what should be the general strategy? Should we go for disabling everything we can or just big ticket things that we know are likely to have an impact that users would notice?

Comment 2

[Paul Morris [:pmorris]]

Attachment: part1-start-stop-alerts-service-0.patch

This patch applies on top of the patches in bug 1626066, so just requesting feedback for now. It starts/stops the alerts service based on whether calendar is activated/deactivated.

Comment 3

[Geoff Lankow (:darktrojan)]

I can't see how the user would notice any of these things was active when no calendars are enabled. Assuming they respond to enabling/disabling events as intended, that is.

Some of the UI parts still need to respond to changes because they remain visible (such as the list of calendars in calendar-management.js) or because they might become visible if a calendar is enabled (such as the today pane). I think trying to shut them down or start them up outside of what they do already is asking to introduce new bugs.

Comment 4

[Philipp Kewisch [:Fallen][☁️📆]]

I think we should strike a balance here on loading/unloading. There are some services that don't have a lot of impact if there are no calendars (I'm guessing calendar manager is one of them), while others might have events that happen more often or include event callbacks or updates that would wake threads more often than without calendar (I'm guessing calendar controller is one of these). We also need to be aware that load/unload has overhead as well.

I think what I would focus on is looking at the performance impact of these, e.g. with devtools. If we can measure what kind of performance impact these have when loaded on startup as opposed to being loaded later or not at all that might help decide which should be dynamically loaded/unloaded.

Comment 5

[Paul Morris [:pmorris]]

With some help from Florian I looked at a performance profile of TB/calendar startup. (https://bit.ly/2y101it) This was with no calendars or calendar data, which would be the case for someone not using calendar.

There are two areas where calendar code is active on startup.

1. calendar custom elements load (connectedCallback calls)
   happens around 2.2 - 2.7 seconds in the startup timeline
   lasts ~350ms

• 122ms calendar-multiday-base-view
• 101ms calendar-minimonth
• 44ms calendar-views
• 38ms calendar-views

2. calendar background services etc. start up (calendar-chrome-startup.js)
   happens around 5.5 - 5.7 seconds in startup timeline
   main segment lasts 108ms
   an earlier smaller segment is 3ms
   from start of earlier segment to end of second is ~143ms

• 80ms setLocaleDefaultPreferences
  • 74ms of that is refreshDissplay in calendar-minimonth.js (custom element)
• 5ms injectCalendarCommandController
• 3ms loadCalendarManager

This is not a profile from a typical user's laptop, which would be slower, especially for File IO if they don't have an SSD hard drive.

It looks like the background processes (from calendar-chrome-startup.js) do not run for long at all on startup. Even on a slower machine, it would have to be 5x slower for that 108ms to exceed a 500ms threshold Philipp and I discussed. Also, there's not one background process that takes more time than the others. If anything the loading/(re-)rendering of the calendar custom elements appear to take the most time in calendar startup.

It was clear from my meeting with Florian that there are a lot of opportunities for improving TB performance (at least for startup and likely in general). Rather than put effort into enabling/disabling the calendar background processes, which could easily introduce bugs, it seems it would be better to put the effort into TB performance in general, working holistically to identify the opportunities for the most significant improvements. That would benefit all TB users, as opposed to what appear to be smaller improvements for only those who aren't using calendar.

So I'm marking this resolved/wontfix (or should it be invalid?).