I was looking at a trace file (compose app), and I saw this huge block of `reportFreeMoveableContent...

# compose

[theapache64]

I was looking at a trace file (compose app), and I saw this huge block of reportFreeMoveableContent in doFrame call (under Crossfade.kt )

Googling what’s reportFreeMoveableContent , I found its way of telling the compiler the elements in the lambda can “move” during layout change. But I don’t understand it 🤔

Questions
• What is ``reportFreeMoveableContent` ? when is it used ?
• Is this normal to have this block in ur trace ? Am i doing something wrong somewhere?

[shikasd]

Is this sampled or traced stack? Depending on how you measure it may introduce additional overhead making this trace bigger than it actually is

Overall, looking into this trace, it seems like you have a heavy movable content lambda that composer is trying to relocate somewhere else. Movable content might introduce substantial overhead in this case, as moving part of composition is not quite simple, which might be what you see here.

[shikasd]

Potential workaround might be to not use movable content in that particular place, or try to hide complex content into subcomposition (e.g. with BoxWithContraints), as movable content will only need to relocate point where compositions connect.
I'd verify the data is correct before jumping into solutions though.

[theapache64]

@shikasd i don't have a direct call to reportFreeMoveableContent or any usage of movable content APIs. I think this is happening from Crossfade 🤔

Btw, i am not sure whats sampled or traced stack.. i recorded the trace file using Debug.startMethodTracing in android

[shikasd]

Yeah, I guess crossfading complicated content might be a bit expensive then, interesting

Method tracing is not really the most optimal, it introduces a lot of overhead for each method call
I'd recommend checking with profiler and sampling profiler instead

[theapache64]

Sure. Will try that. Thanks for the info