Every remember call you have ever written resolves against a data structure called the SlotTable. Since Compose 1.0 that structure has been a gap buffer — the same design a text editor uses to make edits near the cursor cheap. It is the reason remember finds your value by position rather than by name, the reason moving an if branch silently resets state, and the reason key() exists.

In Compose 1.11, Google shipped a rewrite of it.

The new implementation trades the gap buffer for a link-based structure that performs substantially fewer memory copies. Google's own numbers: reordering a long list can recompose more than twice as fast, with most other operations roughly ten percent faster. It requires no recompilation, it applies app-wide including to your dependencies, and it is one flag away — ComposeRuntimeFlags.isLinkBufferComposerEnabled.

This talk uses that rewrite as a way into the part of Compose most developers never see. We start from a decompiled composable and follow one remember call all the way down: what a group is, how the composer walks slots, why positional memoization is the addressing scheme Compose chose, and what the gap buffer's cost model actually is — where it is fast, and where a list reorder turns into repeated array shuffling.

Then we turn the flag on. I will show results from A/B benchmarking the flag on a production banking app's transaction list, including the release-build trap that is easy to miss: the default ProGuard rules shipped with the runtime assume the flag is false, so enabling it in production requires editing your own proguard-rules.pro. We will also look honestly at where the new implementation is still settling, using the bug fixes visible across the 1.11 and 1.12 release notes as the evidence.

You will leave able to reason about your own composables the way the runtime does — and with a measurement you can run on your app on Monday.