Do people here go out of their way to ensure stability of params, etc? I've shipped 5 fully compose ...

# compose

[Colton Idle]

Do people here go out of their way to ensure stability of params, etc? I've shipped 5 fully compose apps over the past 2 years. Millions of users. I have never once written a @Stable annotation or used immutable collections. Never had any perf issues and I've had some complex layouts I've had to implement. Is it just me? Should I be using @stable?

[Pablichjenkov]

Not too worried about that either. No issues/complaints reported so far. 2 Apps different companies with over 1 million each.

[Travis Griggs]

Wow. what kinds of apps are you guys releasing that are getting 1 million users?? I work in Ag Tech. I have many many many fewer users 😄

[Francesc]

there is a middle point between "I don't care about stability" and "everything must be stable". While attempting to have everything stable can add significant overhead, at the same time I think that some effort should be put into it, at least for the low-hanging fruit fixes. Saying "I never had any performance issues" doesn't mean anything other than being anecdotal; having some benchmarking so that there is a basis to determine whether the performance is good enough or not would be the way to go about it. If your benchmarks show an issue, then it'd be worth to delve deeper and figure out what can be improved.

[Pablichjenkov]

Medical devices and Cruise line

[Pablichjenkov]

Yeah I agree it is not like "I don't care about performance". I try the best practices but things like marking everything Stable is a pain. And, also, in some cases still has the risk of someone mutating it accidentally. In which case the UI won't update. I prefer losing a bit of performance but guarantee that every time the states update it is reflected on the screen.
Recently I was talking with a colleague about that. The security and confidence of having every single state change reflected appropriately is more important than performance. Hopefully, folks behind compose keep that philosophy.

[Ben Trengrove [G]]

We are hoping that with the changes being talked about there on the android show, having to mark something as stable will become the edge case we originally intended it to be.

[eygraber]

What are those changes (for those of us that didn't see it)?

[curioustechizen]

There is one situation where I had to use the Stable annotation: when my state class had large lists. That turned into a habit of adding that annotation to every state class that I create.

[Ben Trengrove [G]]

It's called "strong skipping mode". It's an experimental compiler option that makes composables with unstable parameters also able to be skipped

[Pablichjenkov]

So only shallow equality will be checked and delegate the state mutation responsibility to the developer? - Sounds good tbh

[Ben Trengrove [G]]

Unstable parameters will be compared for instance equality

[Pablichjenkov]

Makes sense, will make unstable parameters equality check super fast

[vide]

My team places a lot of care on manual skipping/stability optimization, but we don't deal with modern smartphones. We target ~10 year old embedded devices that barely run compose. There it has proven to be very important to squeeze all potential perf.

[Pablichjenkov]

I agree 💯 with you Elias, but the fact that you mark it as Stable doesn't make it stable. As long as you use specific immutable libraries and proper patterns to update state it is fine. Then someone breaks those rules and things start not working.

[vide]

Marking as stable definitely does make it stable 😅 There are a lot of edge cases where the compiler does not infer it automatically.

[Ben Trengrove [G]]

Marking it stable makes the compiler consider it stable, it doesn't make it stable. Stable means you'll let compose runtime know about any mutations, in practice by using MutableState

[Pablichjenkov]

Check this Elias.

[Pablichjenkov]

In regards to the new approach I am super positive about it. It should have always being like that, instance equality. Developers should know how to play with and propbably there is some edge cases, but it looks like most people are representing state with sealed + data classes and using copy to update the state, which makes the whole thing a great combination.

[Zoltan Demant]

I went pretty hard with @Immutable in an earlier project with performance problems (many complex screens, too). It did resolve the performance issues, but more notably: theres a clear difference in fluidity as compared to newer projects without the optimizations (despite the newer projects using the reworked Modifiers even; they werent available back then). Having the "optimized" version enabled by default would be awesome 👍🏽

[vide]

What I meant with "make it stable" is from the viewpoint of the compiler, because that's usually what matters

[vide]

@Pablichjenkov @Ben Trengrove [G] I am well aware that the annotation doesn't change the class itself, but there are some cases where stability can't be automatically inferred by the compiler; for example when using non-compose aware classes from external sources. In this case you can have a practically stable class that you still need to manually annotate. Another use case is a class with mutable non-state values, where the mutable parts are only read in callbacks, not for producing UI state etc.

[Ben Trengrove [G]]

Yes, no disagreement there

[Pablichjenkov]

Ah I see right, the inverse logic, if you 💯 sure no danger of mutability, not marking it as Stable is bad since you lose the opportunity to optimize. See your point now, good

[eygraber]

@Ben Trengrove [G] is "strong skipping mode" written up anywhere, or is it just discussed in that video? In either case is there a link available for it?

[ascii]

It's not finished yet, so there's no docs for it. Video mentions it'll come out next year:

https://youtu.be/_gL7XZy_XsY?t=3673▾

[Colton Idle]

I wonder if my use of snapshot state for everything that we want compose to recompose lessens the need for marking things as stable.

@Ben Trengrove [G] glad to know the original intention for @Stable was for it to have to be seldom used.

[ascii]

Many things are already interpreted as being stable by the compiler, as long as it can see that code. For example, a data class with only `val`s inside it doesn't need to be marked with any stability annotations.

[ascii]

I'm excited about strong skipping mode. It should've been this way from the beginning imo.

But let's see what weird edge cases pop up later on.

[Ben Trengrove [G]]

No docs and all subject to change, very experimental. You can read the CL though if you want.

https://android-review.googlesource.com/c/platform/frameworks/support/+/2671135

[ascii]

1.5.4 is out, with ^ this and https://r.android.com/c/2668595

[Zoltan Demant]

I dont have time to try this.. I dont have time to try this.. Oooh, shiny!

[Pablichjenkov]

I LL be like com.mypackage.**

[Zoltan Demant]

Strong skipping works perfectly fine for me. Comparing with an earlier project where everything was `@Stable/@Immutable`; pretty much identical - without any of the hassle 😃 Huge thumbs up!

[Colton Idle]

wowowowow!

[vide]

I'll try it this week 👀

[Ben Trengrove [G]]

Good to hear!

[vide]

Tested enabling it, performance is marginally better in some areas that we haven't optimized manually and contain unmemoized lambdas and references to "un"stable external classes. No issues spotted so far.

[Colton Idle]

How do I enable it?

[Francesc]

you can't for now, there is a bug in the compiler that prevents the new flag from being parsed

[Francesc]

there is an open ticket for it

[Francesc]

https://issuetracker.google.com/issues/309765121

[Colton Idle]

Really? A few people here said it worked!

[Francesc]

are you talking about the stability path, where you define a set of classes or packages that the compiler will consider stable (like Kotlin collections)?

[Colton Idle]

Oh sorry. I was talking about "Add a strong skipping mode option"

[ascii]

strong skipping mode is this:

plugin:androidx.compose.compiler.plugins.kotlin:experimentalStrongSkipping=true

Add it to your freeCompilerArgs or in the compose block if CMP.

[ascii]

I've turned it on, removed all the hacks to force-remember stuff like ViewModel callbacks, and it works. Haven't fully tested everything yet though.

[Ben Trengrove [G]]

We just hid that hack in the compiler for you

[Colton Idle]

So

kotlinOptions {
freeCompilerArgs += "pluginandroidx.compose.compiler.plugins.kotlinexperimentalStrongSkipping=true"
}

?

[Ben Trengrove [G]]

Just keep in mind, we consider this very experimental. I wouldn't ship it to production right now

[Colton Idle]

oh yeah. not shipping. just want to see what its all about.

[Colton Idle]

Hm. "Source file or directory not found: pluginandroidx.compose.compiler.plugins.kotlinexperimentalStrongSkipping=true"

[ascii]

You'll have to add "-P" before it

[ascii]

I think as a separate item, i.e. not in the "plugin:" string itself

[Colton Idle]

alright. i have no idea what im doing. so ill keep trialing and erroring. thanks all. seems like im close

[Francesc]

freeCompilerArgs += listOf(
            "-P",
            "plugin:androidx.compose.compiler.plugins.kotlin:experimentalStrongSkipping=true"
        )

[Colton Idle]

thanks! that seemed to work!