What are the (hidden) costs regarding performance of `CompositionLocalProvider`? <https://developer...

# compose

[hfhbd]

What are the (hidden) costs regarding performance of CompositionLocalProvider?

https://developer.android.com/reference/kotlin/androidx/compose/runtime/package-summary#CompositionLocalProvider(kotlin.Array,kotlin.Function0)

[Zach Klippenstein (he/him) [MOD]]

Are there specific hidden costs you’re wondering about, or just if there are any in general?

[hfhbd]

General

[Zach Klippenstein (he/him) [MOD]]

Probably the biggest one would be if you’re providing a static composition local that changes over time, because it will require every composable in the content to recompose.

[Zach Klippenstein (he/him) [MOD]]

I’m not aware of any significant costs to simply providing a value otherwise. Reading a non-static composition local is slightly more expensive than reading a static one, because of the read tracking involved, but it’s not something to be worried about unless your benchmarks show otherwise.

[hfhbd]

So if I update the value "during" recomposition, it will recompose the sub content too. yeah, makes sense

[hfhbd]

I think, I just have to test it 😄

[hfhbd]

Do you know a good compose profiler/benchmark tool? Besides simple measuring the time

[romainguy]

The Jetpack Benchmark library is the best way to write benchmarks

[romainguy]

It tries to ensure consistent measurements in various ways

[romainguy]

Note that beyond performance questions, CompositionLocalProvider can be a “dangerous” tool as it effectively create somewhat invisible dependencies

[romainguy]

Which can make reusing composables more difficult/less obious

[hfhbd]

I know, you should avoid it. My usecase is subtree based relative routing.

[hfhbd]

Thanks for sharing Jetpack Benchmark, but is it possible to measure non ui composables?

[romainguy]

Yes, esp. with microbenchmarks