Does the community have an opinion on creating obj...

# compose

[spierce7]

Does the community have an opinion on creating objects inside of `Composable`s? I've generally held the belief that creating objects inside of `Composable`s, without `remember`ing them, is a bad thing (especially Composables that animate), however I haven't ever been able to measure a performance degredation from this. Is this just some old, outdated thinking from the early days of art, that is no longer applicable?

I recently had a pretty exaggerated case of creating a few simple data classes each frame, vs remembering the objects using their 20 parameters as remember keys, and I found that there was a slight measurable performance improvement by just creating the object.

[Winson Chiu]

You should really only think about this in the animation case or rapid recomposition as you mention. The M3 libraries are covered in single use created data classes for passing in as arguments, like PaddingValues.

That being said, I'm not sure I'd describe a 20 parameter data class as simple. It sounds like something higher up than the UI layer should be handling that class.

[romainguy]

Creating an object is not bad in itself. It becomes an "issue" when it's done at high frequency (animations etc.) and causes unnecessary garbage collection (esp. on older versions of Android/low end devices)

[romainguy]

But definitely don't remember a Rect for instance.

[romainguy]

Remember itself has a bit of overhead

[romainguy]

Anyway as always the answer is: it depends. Profile 😀

[spierce7]

@romainguy the act of creating the object isn’t the problem though, that’s fast, it’s the GC pressure that’s created, or at least that’s how I’ve thought about it. Is that the wrong way to think about it?

Is there an easy way to identify the performance impact of objects you’ve created and the gc while profiling? I’ve always found that challenging.