Is it inefficient to do too many ‘LocalComposition...

# compose

[thelumiereguy]

Is it inefficient to do too many ‘LocalComposition.current.something’ reads in a single composable?
Like LocalComposition.current.colors.primary and LocalComposition.current.colors.secondary.

Would this incur any overheads?

[mattinger]

It's kind of hard to tell. Under the hood, it's this that's being called:

val currentComposer: Composer
    @ReadOnlyComposable
    @Composable get() { throw NotImplementedError("Implemented as an intrinsic") }

Once you have the current composer, there's essentially a map lookup to retrieve the value associated with the CompositionLocal being requested.

So, yes, there is overhead for sure due to the map lookup. To what degree i'm not certain without knowing how this function gets implemented.

The other thing i would say is that if you're not noticing a performance problem, don't worry about it. Premature optimization is rarely worth the effort, and unless you are accessing these values in sort of extended loop, it's likely to not make much difference.

[myanmarking]

why not use MaterialTheme.colors.primary / MaterialTheme.colors.secondary ?