Is there a plan to work on performance of the `runtime`module? My app has huge performance problems and in profiler all the hot paths land in

androidx.compose.runtime

- mostly methods like

ComposerImpl.end

,

ComposerImpl.comsume

,

SlotTable.access

. All other modules like layout, measuring, rendering seem to be OK (except for `Composer.materialize`which is also a very hot path). What do I do - I have simply a Column of like 400 elements, which frankly is not that lot. No LazyColumn because it is even slower and secondly I have to have all the elements instantiated. It is about CfD so I don't have separate release build. (I did manage to get rid of all `sourceInformation-`calls though which did not help much.)

Certainly. When we talk about that we are working performance of the runtime we are talking about the performance of the methods you listed,;though we have not done much in the way of tuning for CfD. The core Compose runtime team has focused primarily on performance for CfA. However, in this case, it sounds like your application is composing too much for every frame. You should check if the composable functions are skipping when the data they are passed is the same as a previous composition. If not, the data is probably not being inferred as stable and which disables our skipping and restarting optimizations as we cannot rely on equality testing to determine if the data has changed.

Nice to hear that! To be more specific the case I talk about is adding (and to lesser extend removing) a group of elements - when user expands or collapses something - that produce a long (few second) lag. As to recompositions of individual ones I did made sure everything possible is stable (e.g. I've marked kotlinx.collections.immutable.PersistantCollection @Immutable). This is still not brilliant but at least I have more means to fight that. Btw. it feels like there might not be much of a need for fine tuning but rather an algorithmical work- e.g. it seems like there are just to many invocations of certain methods for the task to be achieved. The Composer and alike are of course very intricate beasts but I've also seen some obvious things to optimize like

if(map.contains(key)) map.get(key)

.

If you have such optimizations send them my way in any fashion you deem appropriate (patch file, pull request, gerrit CL, etc.).

Yes, I meant that bit in

resolveCompositionLocal

. But generally, couldn't e.g. each group have it's own copy of the composition local map, instead of traversing upwards to find it? It's PersistentMap after all so it can be mostly the same shared instance and lookup seems much more common than providing new locals.

It could but that would almost double the size of the slot table.