hi-manshu Compose performance
Core principle
Measure one user-visible transition, identify the runtime axis that causes the work, then apply the smallest correction at the phase or boundary where that axis begins.
Procedure
- Reproduce one concrete transition and capture the observable evidence: recomposition counts, compiler reports, profiler data, or a clear trace.
- Classify the primary axis: parameter stability and skipping, State read phase, or snapshot state written back into an earlier phase.
- Check for a false lead: a real data change, a correctness defect, or an unchanged lazy item that is expected to recompose.
- Read the corresponding focused reference before proposing a change.
- Change one axis at a time and re-measure the same transition.
- Finish when the evidence improves at the observed boundary without hiding state changes, caching stale values, or moving work to a less correct owner.
Topic router
| Signal | Read |
|---|---|
| Cause is unknown, or several axes may interact | Diagnosis |
classes.txt, composables.txt, strong skipping, unstable parameters, or collection stability |
Stability |
| Scroll, animation, gesture, layout, or draw State read at frame rate; measured state fed back into composition | Deferred reads |
| A composable only reads composition locals or accessor-style values | Composition contracts |
| State ownership or effect lifecycle is the root cause | Compose state and effects |
RED/GREEN agent scenarios
- RED blames unstable parameters for unchanged lazy rows that recompose during a focus transition. GREEN checks composition and layout back-writing first.
- Novel case: an animation value controls only drawing. GREEN reads the State in a draw or layout lambda instead of propagating it through composition.
- Counterexample: a screen visibly recomposes because its displayed model actually changed. GREEN does not add stability wrappers or caches merely to lower a count.