# compose

Hello everyone, I am new to UI programming, and I would like to ask a question: Immutability is a highly respected concept in UI widgets like compose, but when some data changes frequently (such as sensor data) or the data is large (such as editing long text in the form), each change is passed to the ViewModel using an immutable data class. Will it have a significant impact on performance (especially on low-end devices)?

If setup correctly, the data changing often should more often than not, not be an issue, since Compose will only trigger a recomposition (re-render if you will) on the parts of the UI that are reading this state, and not the entire screen. This also reminded me of this library https://github.com/mutualmobile/ComposeSensors which exposes a bunch of the sensor information as compose state directly, so this should make this even easier to get right as I see it.

related article From kotlins lead https://elizarov.medium.com/immutability-we-can-afford-10c0dcb8351d

I think it depends on how low end you are talking about. We have had a lot of challenges getting good perf with frequently changing data (1-10Hz) to nested composables on super low end hardware (old single core embedded).

As the others have said, I think you'll find that Compose is more than able to handle rapidly changing data. Consider that animations are all ultimately built on the same primitives as everything else, and it runs many animations at once with 60fps just fine. Sensor data really isn't all that different in that regard, and just speaking from personal experience doing things with rapidly changing data, I'm consistently amazed at how fast everything works, even when I expected it to be slow. In short, trust Compose to do what it does well, and don't optimize for performance until you actually notice unacceptable degradation in your particular use cases. And with sensor data, this is likely pretty easy to do simply by sampling less frequently (Flows have a lot of great tools for this if you can't control the sensor's sample rate directly)

My definition of low-end might be a little more than usual, I'm sometimes working with 10+ years old hardware that is barely enough to run Android itself... Anyways, if you run into problems, a good approach is to isolate high-frequency state and defer reading it to the deepest possible recomposition scope. You can pass a State or a Flow or a function that you read just before you need to render the actual value. That way you can skip all the recompositions of parent composables.

But I also agree with others. Test first and optimize after. High chances that you won't notice anything

ok thank you very much everyone