# Round 16 — shares-lane & contextMap incremental builders, folder/href/disposition/preview alloc cuts

Benchmark-gated, same rule as ROUND2–15: every change ships with a
BEFORE/AFTER benchmark and an equivalence/safety gate; an AFTER that doesn't
beat its BEFORE is rolled back (never applied). The roll-back rule is encoded
directly into each harness as a `GATE FAIL … rollback` non-zero exit (Rust) or
a threshold `expect()` (frontend), so a regression fails CI rather than
shipping.

This round finishes the **route-level half** of the O(N²/page) grouped-listing
class ROUND15 §F1 fixed *inside* `ResourceList` — the two remaining producers
that feed it (the "My shares" `lanes` tree and the trash/recent/favorites/
shared-with-me `contextMap`) — and lands a backend CPU/alloc micro-pack of four
per-request allocation cuts surfaced by a fresh hot-path audit.

Measured on 4 cores / 15 GiB, **no PostgreSQL needed for any Round-16 arm**
(frontend: Node 22 / vitest; backend: release counting-allocator examples).
Reproduce any row with the command in its section.

## Summary

| # | change | key metric | before → after |
|--:|---|---|---|
| F1 | "My shares" (`shared/+page.svelte`) `lanes` `$derived.by` re-bucketed the WHOLE accumulated grant list on every infinite-scroll page (and every grant edit); `SharedLanesBuilder` re-emits only the fresh page and reuses each untouched lane's array reference | 50×50 (2 500-item) drain | **63 750 → 2 500 `emit` calls (25.5×)** · **8.8× wall** · O(N²/page) → O(N) |
| F2 | trash / recent / favorites / shared-with-me rebuilt a fresh `Map` (hashing every accumulated id) as `contextMap = $derived(new Map(raw.map(…)))` every page; `primeContextPage` holds one persistent `SvelteMap` and sets only the fresh page's entries (mirrors `favoriteIds`, ROUND14 §F2) | 50×50 drain, 4 routes | **63 750 → 2 500 `entry` calls (25.5×)** · **7.2× wall** · O(N²/page) → O(N) |
| M1 | folder display constants — the trash-listing / NC-search-REPORT / path-resolver folder branch built `Arc::<str>::from("fas fa-folder")` (+ 2 more): 3 heap allocs/row where the sibling file branch already used the interned `Arc` clone | 3 fields/folder row | **3.00 → 0.00 allocs/op**, 1.14× wall |
| M2 | `build_content_disposition` — every download + Range seek built an `encoded` String, an `ascii_safe` String, and the `format!` result (3 allocs); fast-path all-attr-char names + single in-place buffer do it in 1 | 5 names/op | **30.00 → 5.00 allocs/op (6×)**, 2.67× wall |
| M3 | `nc_href` — every NC PROPFIND/REPORT href allocated a per-segment `Vec<Cow>`, a joined String and the `format!`; one pre-sized buffer keeps `urlencoding::encode` (identical bytes) | 5 hrefs/op | **38.00 → 27.00 allocs/op**, 1.44× wall |
| M4 | NC preview `fileId` — the handler `collect()`ed the digit prefix into a String only to reparse it to `i64`; parse the borrowed prefix slice instead | 5 ids/op | **4.00 → 0.00 allocs/op**, 2.51× wall |

## [F1] "My shares" — incremental lanes builder

```
cd frontend && npx vitest run src/lib/utils/sharedLanes.bench.test.ts
```

The shares page pages its outgoing grants in via infinite scroll
(`raw = [...raw, ...page.items]`), and the `lanes` `$derived.by` re-bucketed the
whole accumulated (kind-filtered) list on every page — allocating a fresh lane
object and a fresh `rows` array for *every* lane each time — Σ ≈ O(N²/page)
`emit` calls across a drain. It also re-fired on every grant edit (role/expiry/
password), each of which reassigns `raw`, re-bucketing the entire list for a
one-row change.

`SharedLanesBuilder` (extracted to `$lib/utils/sharedLanes`, off the Svelte
reactive graph so it's unit/benchmark-testable) is the F1-flagship pattern
generalized for the lanes shape, which differs from `ResourceList`'s sections
in two ways: **fan-out** (one grant item contributes rows to *many* lanes in the
"shared with" group-by) and a **header captured at first appearance** (vs a
label recomputed each sync). On an append it re-emits only the fresh page and
hands back the same `rows` array reference for every untouched lane, emitting a
fresh array only for lanes the page actually grew. Any non-append (group-by
switch, grant edit, kind-filter toggle) falls back to a full rebuild, so the
output is always deep-equal to the pure `buildLanes` reference — including the
non-contiguous "shared with" group-by, where a page sprays rows across
already-emitted subject lanes (the same non-monotonic case F1 handled for trash
grouped by drive). The O(1) append test is shared with `resourceSections` via
`isAppendExtension` (extracted this round, re-validated by F1's own gate).

50×50 (2 500-item) drain: **63 750 → 2 500 `emit` calls (25.5× fewer), 8.8×
wall**. Gates: (1) equivalence — deep-equal to `buildLanes` at *every* page for
both the by-files (contiguous) and by-subject (non-contiguous fan-out)
group-bys; (2) reference stability — untouched lanes keep their exact array
reference across an append while a grown lane gets a fresh one; (3) correct
fallback on group-by switch, grant edit and kind-filter toggle; (4) perf — the
deterministic O(N) `emit`-call count, plus a best-of-3 wall ≥3×.

## [F2] Grouped routes — incremental `contextMap`

```
cd frontend && npx vitest run src/lib/utils/listContext.bench.test.ts
```

`/trash`, `/recent`, `/favorites` and `/shared-with-me` each fed `ResourceList`
a per-item `contextMap` (`id → ItemContext`, carrying the envelope's date /
owner / drive fields the group-by and row render read) built as
`$derived(new Map(raw.map((it) => [id, ctx])))` — a brand-new Map re-hashing
every accumulated id on **every** infinite-scroll page. O(N) per page ⇒ Σ
O(N²/page) across a drain, and a fresh instance each page invalidated every
reader. ROUND15 §F1 fixed the `sections` half *inside* `ResourceList`; this is
the route-level projection that feeds it, flagged on ROUND14's deferred list and
never landed.

`primeContextPage` (`$lib/utils/listContext`) applies the shipped `favoriteIds`
shape (ROUND14 §F2, a persistent `SvelteSet` primed per page): each route holds
one persistent `SvelteMap` for the component's lifetime and, in `load()`, clears
it on a reset and sets only the freshly-fetched page's entries — O(page) per
page, O(N) across the drain, one stable instance. The map only ever needs to be
a superset of the displayed ids (rows removed by a delete aren't rendered, so
their stale entries are never read), and every id entering `raw` comes through a
`load()` page, so the map always covers what's on screen. `shared-with-me`
passes a drive-skipping entry (drives never reach the row UI), so its map
matches the displayed `fileFolderGrants` exactly.

50×50 drain: **63 750 → 2 500 `entry` calls (25.5× fewer), 7.2× wall**. Gates:
(1) equivalence — the primed map is deep-equal to a full `new Map(cumulative.map(…))`
rebuild at every page, including skipped drives and the reset path; (2) perf —
the deterministic O(N) entry-call count, plus a best-of-3 wall ≥3×.

## [M1]–[M4] Backend CPU/alloc micro-pack

```
cargo run --release --features bench --example bench_round16_micro
```

Counting-allocator micro-bench; each section is BEFORE (verbatim replica of the
shipped-before shape) vs AFTER (the shipped function itself where reachable —
`intern_display`, `nc_href` — else a verbatim replica of the shipped-after
shape), with a byte/-value equivalence gate and a `GATE FAIL … rollback` exit.

- **[M1] Folder display constants → interned clone.** The trash-listing
  (`trash_service.rs`), NC-search-REPORT (`report_handler.rs`) and path-resolver
  (`path_resolver_service.rs`) folder branches each built
  `Arc::<str>::from("fas fa-folder")` + `"folder-icon"` + `"Folder"` — three
  heap allocations + memcpys per folder row — although all three literals are in
  the `DISPLAY_INTERN` closed set and the **file branch of the very same
  function** already used `intern_display` (a lookup + refcount bump, 0 allocs).
  ROUND11 interned the file classifiers on these paths but missed the folder
  constants. Per trashed / searched / resolved folder row: **3.00 → 0.00
  allocs/op, 1.14× wall**.
- **[M2] `build_content_disposition` 3 → 1 alloc.** Called on every download and
  every Range seek (media/PDF scrubbing pays it per seek), it built a
  percent-`encoded` String, an `ascii_safe` filtered String, and the `format!`
  result — 3 allocations. The shipped code fast-paths an all-attr-char name
  (`filename` and `filename*` are the name verbatim → one `format!`) and, for
  names needing encoding, writes the ASCII fallback and percent-encoded form
  into a single pre-sized buffer. Byte-identical across ASCII / spaced / unicode
  / quote+backslash names: **30.00 → 5.00 allocs/op (6×), 2.67× wall** (5
  names/op, a fast/slow mix).
- **[M3] `nc_href` Vec+join → single buffer.** Every NC PROPFIND/REPORT href
  allocated a per-segment `Vec<Cow>`, a joined String and the `format!` result;
  the native WebDAV side already fixed this exact shape (`encode_uri_path`). The
  shipped code writes the prefix, user and each encoded segment straight into one
  pre-sized buffer, keeping `urlencoding::encode` so the emitted bytes are
  unchanged (incl. root trailing slash and internal `//`): **38.00 → 27.00
  allocs/op, 1.44× wall** (5 hrefs/op — the Vec + join + format drop; the
  per-segment encode Cows, unavoidable, remain).
- **[M4] NC preview `fileId` borrow-slice parse.** The preview handler
  `collect()`ed the leading digit run into a String only to reparse it to `i64`;
  the shipped code finds the digit-prefix length and parses the borrowed slice —
  0 allocations. Per NC thumbnail request (a gallery fires one per tile): **4.00
  → 0.00 allocs/op, 2.51× wall** (5 ids/op).

## Not shipped — deferred to a later round

Surfaced by the Round-16 audit but not landed (each wants its own decision,
Postgres fixture, or a larger change):

- **Backend query-shape (needs Postgres):** carried forward from ROUND15 —
  `music_storage_adapter::list_public_playlists` 1 + N `COUNT(*)` fold; contact
  REST listings over-fetching the multi-KB `vcard` TEXT (wants a *lite* row
  mapper).
- **Backend CPU/alloc (no Postgres, next micro-pack):** the two WebDAV PROPFIND
  surfaces still quote `d:getetag` into a fresh String per row and `format!` the
  per-row href per child (the CalDAV §A6 reused-buffer treatment never reached
  them); `delta_upload_service` → `hash_chunk_sequence` clones every chunk hash a
  second time (`.iter().cloned()` on an already-owned Vec — change the signature
  to take it by value); `contact_to_vcard` seeds from a 27-byte String and
  `.to_uppercase()`-allocates each TYPE token.
- **Frontend (vitest-benchmarkable):** `VirtualRows.offsets` prefix-sum is
  rebuilt in full on every photos-timeline page (residual O(N²) on the hottest
  scroll surface — an incremental extend needs care to keep the downstream
  `$derived` reference-invalidation correct); the dotfile filter and
  `ResourceList.itemIndexById` re-scan the whole accumulated list per page (both
  conditional — hide-dotfiles on / an active selection — hence lower priority).

## Environment / methodology

- `cd frontend && npx vitest run src/lib/utils/sharedLanes.bench.test.ts`
  and `… listContext.bench.test.ts` — Node 22 / vitest, no Postgres. Wall gates
  take the best-of-3 (min) per arm to shrug off scheduler/GC noise under a
  saturated runner (round14 §F1 pattern); the deterministic O(N) call-count is
  the primary rollback gate.
- `cargo run --release --features bench --example bench_round16_micro`
  — counting allocator, no Postgres (`BENCH_ITERS`).
- Roll-back rule encoded per harness: the Rust example `std::process::exit(1)`
  with `GATE FAIL … rollback` if an AFTER arm fails to reduce allocations; the
  vitest gates `expect()` the O(N) call count and the ≥3× wall.