Debugging and fixing a *huge* Jetpack Compose performance problem in my Sudoku-solver app.

Android Studio’s recompose visualisations showing just how much the slightest change was causing over 700 text boxes to recompose.
For info (as GIFying things won’t necessarily show it), this video was taken *after* the performance fix, and it looks so much smoother.
In the right column, the blue stacked icon indicates the number of recompositions. The grey cross-circle icon indicates the number of times this composable skipped recomposition.

Stable vs unstable. Why a composable always recomposes.

I really recommend watching Aida’s talk when it becomes available online, but nevertheless, here’s how I worked out the problem.

What my code looks like when I don’t expect anybody will review it. I was going to tidy it up… promise!

Just because you have “MutableList”, doesn’t mean that “List” is immutable, silly.

List is not immutable, it is read-only. This can be shown by an example you’ll almost certainly be aware of, but have probably forgotten (like I did). In your ViewModel you’ll have things like this…

Making Lists stable

There are ways of overriding stability through annotations, but that leaves an icky feeling in my stomach.

ImmutableList means no unnecessary recompositions. Yay!


  1. Use the recomposition feature in Android Studio EE to see just how much your Composables are recomposing.
  2. If it’s recomposing every time, look for unstable parameters, like vars and Lists/Sets/Maps.
  3. Use this library and *never* let your Composable accept a mutable list again.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Chris Ward

Chris Ward

Berliner. Android Engineering Manager. ADHD/Anxiety/Depression sufferer. Posts mainly about tech, politics and mental health.