Hello! In Android Views world creating new objects in `onDraw` callback is considered a bad practic...

# compose

[Anton Shilov]

Hello! In Android Views world creating new objects in onDraw callback is considered a bad practice. In compose official docs we see creating instances of Offset, Path, etc. in DrawScope.
Is it going to be impacting draw performance the same way as in views? Or we shouldn't care about such things in compose world?

[Filip Wiesner]

Not sure about Path but Offset is inline (value) class so that shouldn't be a problem

[ade]

I don't think so, because recomposition doesnt happen on every frame, and if it does you've got a larger problem...

[Anton Shilov]

If you're running an animation it could recompose on every frame and become problematic 🤔

[Albert Chang]

Firstly, many of these (e.g. Offset, Color) are inline classes, which are essentially primitive types, so there isn’t any object allocations when using these classes.
Secondly, that rule was proposed in the early years of Android, when it was still using Dalvik. ART is much better in this respect, and the performance of mobile chips has also improved a lot. Generally I don’t think this should be a big problem now. You can start to think about optimization when you actually see some performance issues.

[Adam Powell]

All of the above is true. 🙂 ART and hardware have improved but putting pressure on the GC when you don't need to comes at a cost. In particular, on modern versions of ART the GC runs concurrently without the kinds of stop the world pauses you might be used to, but the trade-off is that while it's running, field reads involve full memory barriers, making all of the rest of your code on other threads run slower.

[Adam Powell]

It's not free on desktop JVM either, but the characteristics are different

[Adam Powell]

If we didn't worry about it at all then we wouldn't have bothered making the classes mentioned above inline. You'll see that in some very frequent code paths we also make sure to use O(1) indexed collection classes and forEach variants that avoid creating iterators.

[Adam Powell]

All that said, we've done this in the deeper compose internals so that in the common case, you don't have to go this far yourself in your own code unless you've measured a problem. Hardware and software have gotten better here. Keep it in mind, don't be unnecessarily wasteful, but don't tie your code completely in knots for something you haven't measured either.

[Adam Powell]

Modifier.drawWithCache is a good example of an API designed for helping you with this; you get an outer block for creating things you might reuse over time and an inner block for drawing using those same object instances

[Filip Wiesner]

we've done this in the deeper compose internals so that in the common case, you don't have to go this far yourself

Same reasoning as with enums in the "old days" (enums being represented with Integers instead of an actual enum)

[Adam Powell]

Eh, kinda. 🙂 With the direction Kotlin took with exhaustive when around enums it's a really good thing Android mostly didn't use them, since exhaustive when means adding a new enum value is both binary and source breaking, whereas in plenty of cases with Java you can get away with it

[Adam Powell]

And if you have thousands of them, they really do add up in terms of overhead unless you have a whole-program shrinker like r8 eliminate them and reduce them to primitives. Can't do that across a dynamically linked API boundary, at least not yet.

[Adam Powell]

Avoiding the exhaustive when gotcha and being able to compatibly add new values to a type is why compose uses inline value classes for a lot of things instead of enums

[Filip Wiesner]

Fair enough 👌 Thanks for the explanation

[Anton Shilov]

Thank you for the detailed explanation Adam 🙏