Channel list: slow at login, and redrawn in full for every post read #238

New issue

Closed

opened 2026-10-21 19:22:20 +00:00 by littlefox · 1 comment

littlefox commented

2026-10-21 19:22:20 +00:00

Owner

Found in the performance review (#230, D-058).

The left column (app/src/main_view/conf_nav.rs) has two resources, overview and mine, that cost more than they need to.

At login:

mine asks the server for the name of every membership, one at a time (conf_name in a loop). With 400 memberships at 30 ms that is 12 s before the list is complete. Batch it (small parallel chunks, as BATCH elsewhere), and draw names as they come.
overview counts the unread posts of each conference one at a time, by paging the whole unread range with local-to-global in batches of MAP_BATCH = 100. A conference with 5 000 unread takes 50 sequential calls before its count shows.
- Use the protocol's maximum (255).
- Show an estimate first, from highest-local-no and the read ranges we already have. Refine it in the background.
- Count the conferences on screen first.

After login: both resources read tick() and changes().

tick goes up for every post read (also by scrolling, #180).
changes goes up for every login and logout on the server.
So each of these rebuilds and redraws the whole channel list, both sections, and the conference names are looked up again (cached, but still awaited one by one).
The counts are already kept locally, so subscribe to changed counts instead, and redraw only the rows that changed.

Measure with #225: time from login until the channel list is complete, for a person with ~300 memberships (add one to the seed), and redraws of the left column per post read.

Found in the performance review (#230, D-058). The left column (`app/src/main_view/conf_nav.rs`) has two resources, `overview` and `mine`, that cost more than they need to. **At login:** - `mine` asks the server for the name of **every membership, one at a time** (`conf_name` in a loop). With 400 memberships at 30 ms that is 12 s before the list is complete. Batch it (small parallel chunks, as `BATCH` elsewhere), and draw names as they come. - `overview` counts the unread posts of each conference **one at a time**, by paging the whole unread range with `local-to-global` in batches of `MAP_BATCH = 100`. A conference with 5 000 unread takes 50 sequential calls before its count shows. - Use the protocol's maximum (255). - Show an estimate first, from `highest-local-no` and the read ranges we already have. Refine it in the background. - Count the conferences on screen first. **After login:** both resources read `tick()` and `changes()`. - `tick` goes up for **every post read** (also by scrolling, #180). - `changes` goes up for every login and logout on the server. - So each of these rebuilds and redraws the whole channel list, both sections, and the conference names are looked up again (cached, but still awaited one by one). - The counts are already kept locally, so subscribe to *changed counts* instead, and redraw only the rows that changed. Measure with #225: time from login until the channel list is complete, for a person with ~300 memberships (add one to the seed), and redraws of the left column per post read.

littlefox added this to the 0.6: Performance milestone

2026-10-21 19:22:20 +00:00

littlefox added the

area/ui

area/protocol

kind/bug

labels

2026-10-21 19:22:20 +00:00

littlefox referenced this issue from a pull request that will close it,

2026-10-22 02:27:31 +00:00

Channel list at login: counts six at a time, read ranges in one call #262

littlefox referenced this issue from a commit

2026-10-22 02:27:31 +00:00

Channel list at login: counts six at a time, read ranges in one call

littlefox closed this issue

2026-10-22 04:34:00 +00:00

littlefox commented

2026-10-22 05:13:19 +00:00

Author

Owner

Merged in #262; main run #439 green. Verified: devserver tests, full e2e on three profiles (332 passed), and tools/perf.sh: with 300 channels plus Stort möte and the mailbox (30 ms each way), all 301 channels listed after 6.7 s instead of 42.4 s, login calls 1 656 → 972. The list is still rebuilt after each batch of marks, with no calls now; the rows themselves are cheap.

Merged in #262; main run #439 green. Verified: devserver tests, full e2e on three profiles (332 passed), and `tools/perf.sh`: with 300 channels plus Stort möte and the mailbox (30 ms each way), all 301 channels listed after 6.7 s instead of 42.4 s, login calls 1 656 → 972. The list is still rebuilt after each batch of marks, with no calls now; the rows themselves are cheap.