Should there be primitive friendly overloads of `derivedStateOf` like for `mutableIntStateOf`, `muta...

# compose

[louiscad]

Should there be primitive friendly overloads of derivedStateOf like for mutableIntStateOf, mutableFloatStateOf, and mutableDoubleStateOf, to avoid autoboxing?

[shikasd]

Not really, derived state is quite expensive by itself, so you won't be saving much on boxing

[louiscad]

What makes derivedStateOf expensive?

[shikasd]

Caching / invalidation logic mostly

[louiscad]

Is it more expensive than using SnapshotStateObserver directly?

[shikasd]

They are orthogonal tbh, you can't use one without the other

[shikasd]

well you /can/, but it won't invalidate/track changes correctly

[louiscad]

blob thinking fast

[louiscad]

derivedStateOf is backed by SnapshotStateObserver, right?

[louiscad]

Calling observeReads on it somewhere?

[shikasd]

Not really, derived state works independently from it

[shikasd]

Derived state is practically a lambda that has some caching mechanisms to avoid invalidating context where it is read in

[louiscad]

Why SnapshotStateObserver wouldn't work the same if you update the final MutableState or Mutable*State, in the change observer lambda, granted that SnapshotStateObserver was started?

[shikasd]

It is practically a difference between hot and cold observable in this case
Derived state is cold, state updated through observer is hot

[shikasd]

That allows to skip processing derived states that are never read, for example

[louiscad]

Same happens with SnapshotStateObserver if you don't call observeReads at all, right?

[louiscad]

But okay, I think I see roughly why one can't implement derivedStateOf with just SnapshotStateObserver

[shikasd]

You probably could just use something closer to what snapshotFlow does. SnapshotStateObserver is pretty heavy for observing single state, it is meant to be created once per owner and can create multiple observation contexts

[louiscad]

All other things equal, if I have to decide between using derivedStateOf, and calling this function even if unneeded, which one should I pick, or is there a way to compare the cost calling the function, vs having derivedStateOf unread, vs having derivedStateOf read and running the computation?

fun angle(refAxis: Float, a: Float) = Math.toDegrees(acos(refAxis.toDouble() / a))

[shikasd]

So derived state is like 100 times slower than reading from a map iirc?

[shikasd]

The case above is definitely fine to be just a function

[louiscad]

Use case is drawing a watch face, so efficiency and power consumption is top-priority

[louiscad]

If I understand correcly, computing angle eagerly would be more desirable than using a remembered derivedStateOf, or using SnapshotStateObserver?

[shikasd]

Yep, it doesn't sound like a lot of math here, and computers are really good at it
They are less good at hashmaps and allocations which both state approaches will cause

[shikasd]

In general, I recommend to benchmark things like that
Simple benchmarks are easy to setup and can provide a lot of insight into computational price of caching vs re-executing, for example

[louiscad]

Are there example benchmarks for this kind of Compose runtime things that don't involve all the Compose UI machinery?

[shikasd]

They are not really different from any other Android benchmark

[shikasd]

We have some internally, but those are too involved I believe

[louiscad]

I'm not sure how I'd go about testing the cost of derivedStateOf when recomposing for example blob thinking fast

[louiscad]

Feels like a of setup would be required to test a tiny little thing

[shikasd]

Right, this one is a bit more complicated, and probably noise from spinning recomposition will be much higher than the actual execution time

[louiscad]

I would test without recompositions, too

[louiscad]

For states read at render time for example

[shikasd]

I meant something like comparing state.value and runtime of the function itself

[louiscad]

You mean calling state.value itself has some cost that might be higher than, say, the angle function I showed?

[ephemient]

likely. math is just cpu cycles, state needs to follow multiple links through memory

[shikasd]

in derived state case, it needs to verify that state didn't change as well, so it is even more expensive

[shikasd]

in fact, state.value in general is quite expensive

[louiscad]

Are there cases where the cost of state.value can vary?

[louiscad]

For example, based on which thread it is called on, or at which stage it is called.

[shikasd]

Yeah, main thread is a bit more optimized + it depends on read observer for the snapshot, so when something observes the state, it is more expensive

[louiscad]

What makes it that an observed state is more expensive to read from exactly? Is it calling observers synchronously before returning from `value`'s getter?

[shikasd]

Yep, exactly

[louiscad]

I was pondering last night, is calling map { it % 2 }.distinctUntilChanged().collect { } on a StateFlow<Int> cheaper than having a derivedStateOf doing the same over a MutableIntState or a MutableState<Int>?

[shikasd]

It depends?

How do you use this flow, is it consumed in composition or somewhere else? You might also want to run LaunchedEffect for the flow, where coroutines also have some cost associated with it.

[louiscad]

Outside of a composable function, not in Compose UI

[shikasd]

Right, I'd probably go with Flow here, it's likely to be faster and also more reasonable for non-observable scopes.
The only way to figure out what is faster is to run a benchmark though 😄