1789730 - Slow startup due to recurring event with many annual occurrences

Status: NEW

(Calendar :: Internal Components, defect)

Description

[BobS]

Steps to reproduce:

Start with new profile and new local calendar (issue occurs also on internet calendars).
Create a recurring event:

• Repeat: Annually every 1 year
• Range of recurrence: Create 200 Appointments
  Restart TB

Actual results:

TB takes about 30 seconds to start.

Startup time appears to increase with the square of the number of appointments specified for the event.

Problem does not occur if event is changed to unlimited appointments.

Problem seems to be a function of calendar duration -- 200 weekly appointments cause little or no startup delay.

Problem was initially observed after upgrading from 91.10.0 to 102.2.1, where my Gmail calendar was causing a 15 minute startup delay due to many such recurring events. Problem does not occur on 91.10.0.

Expected results:

Recurring events should cause no significant delay in startup, as with version 91.10.0.

At the very least, logging in the Activity Manager the calendar/events which are causing excessive startup time, with a suggested solution (e.g. changing to unlimited recurrences) would have saved me several days of troubleshooting.

Comment 1

[Wayne Mery (:wsmwk)]

Your cite version 106 in the bug report, so you tried Thunderbird nightly build?

Bug 1789999 introduced a fix on 9-19-2022. Is your issue better, fixed, or worse with a newer nightly build?

If not fixed, please obtain a performance profile using https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance and post the URL here. Thanks.

Comment 2

[BobS]

Tested with 107.0a1 (2022-09-25). Problem is much improved, thank you!

There is no noticeable startup delay with 200 annual occurrences. I found that the startup delay becomes noticeable (3~10 seconds) at the following points:

Repeat		Occurrences	Span (Years)
Yearly		1000		1000
Monthly		10000		833
Weekly		20000		385
Daily		30000		82

While it's arguable that the these numbers are beyond a reasonable use case, users might enter a large value without realizing the implications, and it is difficult to diagnose a slow startup situation due to one (or many) such calendar entries.

I think it would be helpful to implement one or more of the following:

• A limit on the number of occurrences (with some kind of warning) based on the Repeat type, when loading a calendar (local or web), and when creating an event in TB.
• A message somewhere (Activity Manager, popup dialog, log file) that an event with many occurrences may be contributing to a slow startup.

Comment 3

[Andrei Hajdukewycz [:sancus]]

Geoff, do you think we need to make further improvements on this? I know you were working on startup performance improvements.

Comment 4

[Geoff Lankow (:darktrojan)]

I do. There's a possible optimisation here I've been thinking about for some time, but I haven't figured out how to do it yet.

Ironically the problem is caused by a performance optimisation I implemented a while ago, which works out when an event stops occurring so it can be ignored. Unfortunately that involves working out when all the occurrences are, and that takes a while in these edge cases.

I'll leave the NI flag here as a reminder to have a look when I have some time.

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to Geoff Lankow (:darktrojan) from comment #4)

I do. There's a possible optimisation here I've been thinking about for some time, but I haven't figured out how to do it yet.

Can you share a little bit about this? Perhaps someone else can take up the torch.

Ironically the problem is caused by a performance optimisation I implemented a while ago, which works out when an event stops occurring so it can be ignored. Unfortunately that involves working out when all the occurrences are, and that takes a while in these edge cases.

Which of these (bug 1856509, bug 1787677, bug 1590665) will have caused this?