mcpField
C
compose-performance

compose-performance

github.com/chrisbanesDevelopment1.1k1.1k installsUpdated 1d ago
Repository

About compose-performance

A coding skill for diagnosing and improving Jetpack Compose performance. It uses evidence from a specific UI transition to target stability, state-read phase, or snapshot write-back issues.

Key features

  1. 01Measure a concrete UI transition
  2. 02Classify the source of runtime work
  3. 03Check false leads before changes
  4. 04Apply focused fixes and remeasure

Use cases

  1. 01Investigating excessive recomposition
  2. 02Reviewing unstable Compose parameters
  3. 03Tracing frame-rate state reads
  4. 04Evaluating state written into earlier phases

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/chrisbanes/skills --skill compose-performance

After installing, type/compose-performancein Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
composition-contracts.md
deferred-reads.md
diagnosis.md
stability.md

Details

From the project README

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

  1. Reproduce one concrete transition and capture the observable evidence: recomposition counts, compiler reports, profiler data, or a clear trace. Build only through Gradle run. If no build can run, reason from the declared types; do not unpack toolchain jars or work around the sandbox.
  2. Classify the primary axis: parameter stability and skipping, State read phase, or snapshot state written back into an earlier phase.
  3. Check for a false lead: a real data change, a correctness defect, or an unchanged lazy item that is expected to recompose.
  4. Read the corresponding focused reference before proposing a change.
  5. For review work, pair every finding with the smallest evidence-supported repair. For a false stability promise, explicitly say to replace mutable non-snapshot properties with immutable data or snapshot-observable state, verify that contract, and only then decide whether an annotation remains needed. For a phase problem, name the layout or draw consumer where the changing read or calculation should move. A cross-phase write proves invalidation or an extra pass; do not claim oscillation or an infinite loop unless evidence shows values repeatedly changing. Do not stop at diagnosis. When only source code is available, separate the proven feedback path from its unmeasured runtime cost. Give a conditional repair direction based on the intended measurement boundary; do not prescribe a callback swap, equality guard, or content-layout rewrite as a performance fix without evidence that it changes the observed problem. For an Int held in mutableStateOf with the default structural equality policy, an unchanged value already avoids invalidation.
  6. Change one axis at a time and re-measure the same transition.
  7. 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

SignalRead
Cause is unknown, or several axes may interactDiagnosis
classes.txt, composables.txt, strong skipping, unstable parameters, or collection stabilityStability
Scroll, animation, gesture, layout, or draw State read at frame rate; measured state fed back into compositionDeferred reads
A composable only reads composition locals or accessor-style valuesComposition contracts
State ownership or effect lifecycle is the root causeCompose state and effects

Comments

Markdown supported