One @Observable read re-runs the whole container's Render scope, and lazy items re-Evaluate every pass — stable ids never translate into Compose skipping

[Aecasorg]

Environment

• skip 1.9.4, skip-fuse-ui 1.17.2, skip-ui 1.57.0, skip-model 1.7.5
• Fuse app; Kotlin 2.3.0, compileSdk 35
• Related: NavigationStack recomposing problem #462 (NavigationStack recomposition) looks like a symptom of the same granularity design; fix(android): disable List item placement animations #478 touched the animateItem corner of this from another angle.

Summary

Two related design points in SkipUI combine so that state invalidation on Android is per-container where SwiftUI (and idiomatic Compose) is per-view / per-row:

1. Observation registers on the enclosing container's single restart scope, so one @Observable write re-runs the whole container and all its children.
2. Lazy containers rebuild their item factories and re-evaluate all visible items on every pass, so even perfectly stable ForEach ids don't let Compose skip unchanged rows.

Together these mean the cost of any state change scales with everything on screen rather than with what changed. App code can shrink the blast radius (small child views, reads pushed to leaves, lazy containers) but can never reach per-view granularity, because both mechanisms are framework-owned.

Mechanism A — container-scope invalidation

ComposeBuilder content lambdas return a ComposeResult, which deliberately makes them non-restartable:

// Compose/ComposeBuilder.swift:49
// - Note: Returning a result from `content` is important. This prevents Compose from recomposing
//   `content` on its own. Instead, a change that would recompose `content` elevates to our void
//   `Renderable.Render`.

View.Evaluate (View/View.swift:67) is a value-returning @Composable where each child's body actually executes, and containers call it inline as the first line of their own restartable Render:

// Containers/VStack.swift:53
let renderables = content.Evaluate(context: context, options: 0).filter { !$0.isSwiftUIEmptyView }

So every @Observable read in any child body registers on the container's single restart scope; a mutation bumps the backing state (skip-model MutableStateBacking.swift:46, state[index].value += 1) and invalidates that one coarse scope, re-running the container and re-evaluating every child — including children that never read the mutated value. StateTracking.pushBody/popBody manage the read cursor but do not open a per-view restart group.

Mechanism B — lazy items re-evaluated every pass, no memo boundary

LazyVStack.Render re-runs content.EvaluateLazyItems(level: 0, ...) unconditionally (Containers/LazyVStack.swift:69), and the remembered LazyItemCollector is re-initialized inside the LazyColumn body with freshly allocated factory closures each pass (LazyVStack.swift:128, LazySupport.swift:145 content.removeAll() then reassigns item/indexedItems).

The registered item body is factory(index + range.start, scopedContext).Render(...) (LazyVStack.swift:139), and the ForEach factory internally does a fresh .Evaluate(options: 0) building new Renderables on every run (Containers/ForEach.swift:205–212). A stable key therefore prevents slot destruction/reordering — but never composition skipping: the lambda is a new instance per registration and returns new unstable objects, so Compose can't prove skippability.

List additionally wraps rows in Modifier.animateItem() and runs a recurring time-keyed churn (List.swift:267–270: LaunchedEffect(System.currentTimeMillis()) { delay(300); forceUnanimatedItems.value = false }) that recomposes idle, static lists. The // SKIP INSERT: @Stable comment on List itself (List.swift:102) shows the codebase already fights exactly this instability cascade internally.

Impact

Measured in a Fuse app with a lazy list of ~10 visible rows: any single @Observable write on the screen (a countdown label, a badge) re-runs the container body and full Evaluate+Render for every visible row, every time. On iOS the identical SwiftUI code re-bodies one view. This is the dominant residual cost after all the app-side hygiene we could find (lazy containers, stable ids, precomputed row strings, no geometry feedback loops) — profiling shows recomposition counts per state change equal to the visible subtree size rather than 1.

Suggested direction

• Wrap each composed child in its own void restartable @Composable so its observable reads attribute to a child scope (or split Evaluate so structural reads land on the container and value reads on per-child scopes).
• Remember lazy item factories across recompositions keyed by content id instead of reallocating per pass, and put a remember/movableContentOf boundary (keyed by id + content version) around item bodies so stable ids buy actual skipping.
• Skip animateItem() when the list has no move animations pending, and drive forceUnanimatedItems off data-version changes rather than a wall-clock LaunchedEffect.

Repro

https://github.com/Aecasorg/skip-fuse-perf-repro — scene 1 (UnrelatedStateScene), with a toggle between an eager VStack and a LazyVStack with stable Identifiable ids: the per-second body-evaluation log shows every visible row re-evaluating on each unrelated @Observable tick in both variants.

Offer

We're happy to work on PRs for the item-factory memoization pieces with your guidance — the per-child restart-scope design likely needs your direction first. Would you accept changes along these lines?

[Aecasorg]

On-device confirmation with numbers (CI-built APK of https://github.com/Aecasorg/skip-fuse-perf-repro, API 35 emulator, skip-ui 1.57.0 and 1.59.1 — identical results):

• Unrelated-state amplification: a screen with one @Observable counter read only by a header Text, plus 20 fully static cards. Every 1s tick re-evaluates all 20 cards: the card body-eval counter grows +20/tick, indefinitely (tick=12 … StaticCardView=240). Identical in the eager VStack and the LazyVStack + stable-Identifiable-ids variants — stable ids buy no skipping.
• Navigation cost: each screen open runs the same content ~27 times before settling, and pushing/popping re-runs full backstack screens (+26 to a background screen's counter per navigation event).

Scene 1 of the repro app reproduces this in ~80 lines. On iOS the identical code re-bodies only the header Text.

[Aecasorg]

Follow-up after tracing the pipeline to design a PR for this. The finding reframes the issue, so it seems worth writing up rather than filing a patch that couldn't work.

Per-item memoization and per-child restart scopes cannot be added on top of the current evaluation pipeline — and the reason is upstream of the peer-stability problem I raised in skip-bridge#113.

The Compose compiler emits restart-and-skip logic (startRestartGroup + updateScope) only for Unit-returning composables. SkipUI's evaluation pipeline is value-returning throughout — View.Evaluate → List<Renderable>, ComposeBuilder.Compose → ComposeResult, and the lazy item factory → Renderable (ForEach.swift:207-218, invoked at List.swift:319 / LazyVStack.swift:139). This is deliberate, per the note at ComposeBuilder.swift:49-50: returning a result "prevents Compose from recomposing content on its own. Instead, a change that would recompose content elevates to our void Renderable.Render."

Consequences for the two suggestions in my original report:

1. "Remember per-item factory closures / wrap item bodies in remember or movableContentOf keyed by id." The item factory has no recompose scope of its own, so it re-executes unconditionally whenever the enclosing item scope invalidates. remember can hold the non-composable part (building the item's View), but the expensive part — Evaluate, which runs the body — is @Composable and cannot be cached that way. movableContentOf preserves state across moves; it never suppresses re-invocation.

2. "Wrap each composed child in its own void restartable composable." Inside Evaluate this would be incorrect, not merely risky: the Composer callback appends into a MutableList captured from the enclosing Evaluate call (ComposeBuilder.swift:72-84). A child recomposing on its own would append into a list belonging to a completed pass — silently dropped, no crash and no log.

So the per-view granularity ask really amounts to making the evaluation pipeline void-returning (or introducing a parallel void path for children that don't participate in the accumulator), which is your architectural call, not something contributable as a patch. If you'd consider such a direction we'd gladly help prototype it — but we didn't want to leave a filed issue implying a small fix exists.

Two related notes from the same investigation:

• Fuse amplifies this by roughly 10–100× per wasted evaluation. Each re-evaluation of a bridged child costs two JNI hops plus a fresh SwiftValueTypeBox/peer allocation and a Swift view-tree rebuild, per bridged view per level. The same skip-ui invalidation is nearly free in a transpiled app and dominant in a Fuse app — which may explain why this has not been more visible.
• EquatableView is currently a pass-through (EquatableView.swift:18-20) while SkipSwiftUI.EquatableView bridges into it with an Equatable-constrained content type, so its peer does get structural equality. That looks like the one place an opt-in memoization could legitimately live. We did not attempt it, because on a cache hit the Swift body never runs, so MutableStateBacking.access never re-registers the scope as a reader and subsequent @Observable mutations would not invalidate — the content would silently freeze. Making it safe needs a "this body performed no tracked reads" signal that skip-model doesn't expose today.

Separately, a small self-contained fix from the same area is in PR (linked shortly): List.shouldAnimateItems() is evaluated inside each of the four item-production lambdas, which subscribes every visible row's own composition scope to forceUnanimatedItems and isSearching; one flip then invalidates and re-runs every visible row. The predicate is identical for all items within a pass, so it can be read once in the LazyColumn scope.

[Aecasorg]

One scoping note on our own comment above, so it is not read more broadly than we meant it.

We said the +20-evaluations-per-tick amplification is "identical in the eager VStack and the LazyVStack + stable-Identifiable-ids variants". That is accurate for what it measured — 20 card-body evaluations per tick, one per card, when unrelated state changes — and we have re-checked that scene 1's ForEach is a direct child of its LazyVStack with a single top-level view per element, so the number is not contaminated by the flattening problem we have now filed as #508.

Two caveats on our own instrument while we are here: it is a body-evaluation counter, so "rows already registered as lazy items" was our inference, not something the counter can show; and we did not record how many of the 20 cards were actually on screen.

The reason for the note: a reader can take that sentence as "LazyVStack buys nothing on Android", and for first paint that is not true. On our production order-detail sheet with a 100-line list:

arm	cold open, tap → content reaches the bottom of the screen	n
eager VStack, no lazy container	1640 ms (800–4442)	11
LazyVStack with the rows as direct children, one top-level view each	400 ms (360–520)	6

Provenance, since our earlier comment on this issue was careful about it and these numbers come from somewhere else: arm64 emulator (API 35), debug build of our production driver app, not the linked repro — and built against our fork of skip-ui pinned 1.59.1004, which carries our unmerged Presentation.swift / ComposeExtensions.swift patches (#499 / #505). Cold open is an automated luminance probe over a screen recording sampled every 40 ms, with the endpoint defined as content reaching the bottom of the screen — a stricter threshold than "first content pixel", so absolute values run roughly 100 ms above a hand-read figure. The two arms also differ in per-row padding, so the delta is the whole app-side change, not the container alone.

So: the lazy container is worth a lot for first paint on this screen, while this issue's finding — that it does not additionally buy Compose skipping on subsequent unrelated invalidations, on the 1.57.0 and 1.59.1 we measured — stands unaffected. Two different claims; we only meant the second.