Slow event loading (~10s) that degrades over time

[kraenhansen]

Hi folks - I'm experiencing some performance issues with the app displaying events and I had Claude do some digging - results are below. Let me know what you think might be the best cause of action and I'd be happy to (have Claude) spin up a PR which fix some of this.

Problem

Event loading takes ~10 seconds before events appear on screen, and this degrades over time as more events accumulate in the local database. Clearing app data temporarily resolves the issue, suggesting the problem is related to local data growth rather than network latency.

The architecture is designed to show cached events instantly (DB queries and network fetch run in parallel), but the processing between DB query result and UI render is the bottleneck — decrypt + expand happens synchronously on every render.

Root Causes

1. Decrypt + expand under a global mutex

In GetUiEventsUseCase.kt:133, a single mutex.withLock serializes:

• Decrypting every event (PGP session key decrypt + signature verification — per event)
• Expanding recurring events (RRULE expansion generates all occurrences up to the window end)
• N+1 UID queries — selectEventEntitiesByUids runs one LIKE '%UID:..%' query per UID instead of batching

This all happens on every emission from the combine() of 4 DB flows, before the UI receives any Success result.

2. Unbounded infinite recurring query

EventOccurrencesDao.selectInfiniteRecurring() fetches ALL infinite recurring events where firstOccurrenceStartTime <= toDate — there is no lower bound. As users accumulate weekly meetings, birthdays, etc., this result set grows monotonically and never shrinks.

3. Missing database indexes

The only index on events_occurrences is on eventId. The three event queries effectively do table scans filtering on (userId, calendarId, rRule, startTime, endTime, lastOccurrenceEndTime).

4. O(n²) filter on infinite recurring events

The notOccurring filter (GetUiEventsUseCase.kt:112-118) uses nested filterNot { recurring -> notOccurring.any { ... } } instead of a Set-based lookup.

5. Unbounded decryption cache

EventDecryptorImpl uses a ConcurrentHashMap with no size limit, keyed on (eventId, calendarId, modifyTime). This grows indefinitely without eviction.

Suggested Improvements (rough priority order)

1. Add composite indexes on events_occurrences for the three query patterns (non-recurring, finite recurring, infinite recurring)
2. Bound the infinite recurring query — add a lower bound or use a heuristic to exclude very old recurring events that can't possibly have occurrences in the requested window
3. Batch selectEventEntitiesByUids — the DAO already has an unused selectByUidIn() method that could replace the N individual LIKE queries
4. Replace O(n²) filter with a Set<Triple<userId, calendarId, eventId>> lookup
5. Cap decryption cache with LRU eviction (e.g. 5,000 entries)
6. Pre-decrypt on sync — decrypt and cache events when they arrive from the network, rather than deferring all crypto to UI render time

Notes

• The iOS calendar app (ProtonMail/ios-calendar) reportedly does not have this issue, suggesting a different caching/decryption strategy
• The GetMinimalCalendarEventsUseCase ("minimal" = single calendar, current month) still performs full decryption — there is no lightweight render path

[kraenhansen]

iOS Comparison (ProtonMail/ios-calendar)

Investigated how the iOS app handles the same problem. It reportedly does not have the same performance issue. Here are the key architectural differences:

1. Decryption timing (biggest impact)

	Android	iOS
PGP decrypt	On every render (on-demand), serialized behind a global mutex	Once at sync/fetch time
Storage	Encrypted events in DB	Decrypted ICS re-encrypted with a fast symmetric main key (XChaCha20 via Keymaker); metadata (dtstart, dtend, rrule) stored in plaintext
Display-time crypto	Full PGP: session key decrypt + data decrypt + signature verify, per event	Single fast symmetric decrypt per event

Android does full PGP decryption every time events are displayed. iOS does PGP once when events arrive from the API, then stores the result locally re-encrypted with a cheap symmetric key. At render time, iOS only pays the cost of one symmetric decrypt per event — orders of magnitude faster than PGP.

2. No pre-computed occurrences table

	Android	iOS
Schema	Separate events_occurrences table with pre-computed window times	No occurrences table; RRULE stored on the event entity, expanded on the fly
Infinite recurring query	WHERE lastOccurrenceEndTime IS NULL AND firstOccurrenceStartTime <= :to — unbounded, result set grows over time	WHERE rrule IS NOT NULL AND calendarID = :id — fetches base events only, expands within bounded window
Expansion	Generates all occurrences across the full window, then filters	Expands RRULE only within [leftBoundDate, rightBoundDate] (typically one month)

Both apps fetch all recurring base events, but the critical difference is expansion bounding. iOS never generates more than ~1 month of occurrences at a time. Android's events_occurrences table and expansion windows create an ever-growing dataset — this is why clearing app data temporarily "fixes" performance.

3. UID lookups (N+1 problem)

	Android	iOS
Single edit lookup	N individual LIKE '%UID:..%' queries via selectEventEntitiesByUids (one per UID)	Single Core Data predicate fetch per recurring series

Android has an unused selectByUidIn() batch method that could replace this.

4. Summary: Why iOS feels instant

1. Cheap render-time crypto — symmetric key decrypt vs full PGP per event
2. Bounded RRULE expansion — only expand occurrences for the visible month, never thousands
3. No accumulating occurrence data — no events_occurrences table that grows unbounded over time
4. Plaintext metadata — dtstart/dtend/rrule are queryable without any decryption
5. Core Data reactivity — cached events render immediately from the local store with minimal processing

Relevant iOS source files

• EventsDecryptionStore.swift — sync-time PGP decryption pipeline
• CoreDataManagerEvent.swift — display-time symmetric decrypt + RRULE expansion
• EventStorage.swift — query predicates (bounded non-recurring, unbounded recurring base events)
• EventsRepository.swift — reactive event stream with 500ms throttle

🤖 Generated with Claude Code

[Dosenwerfer]

I run into this issue as well and it is super annoying, borderline makes the app unusable. Having to wait 10-20 seconds each time you open the app before you can do anything is unacceptable. I also have a lot of events in multiple calendars, so it really seems to be a scaling issue. Please include stress testing in your QA and solve this. Thank you.