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

?

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

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 😄

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.

Medical devices and Cruise line

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.

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

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.

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

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

Unstable parameters will be compared for instance equality

Makes sense, will make unstable parameters equality check super fast

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.

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.

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

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

Check this Elias.

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 👍🏽

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

Yes, no disagreement there

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

@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?

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

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.

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.

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

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

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

I LL be like

com.mypackage.**

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!

wowowowow!

I'll try it this week 👀

Good to hear!

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.

How do I enable it?

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

Really? A few people here said it worked!

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)?

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

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.

We just hid that hack in the compiler for you

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

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

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

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

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

thanks! that seemed to work!