compose's `setContent` seems to be drawing too muc...

# compose

[Adib Faramarzi]

compose's setContent seems to be drawing too much CPU time. Is it natural?

[Adib Faramarzi]

We have multiple fragments that use setContent and navigating to one of them seems to be doing some heavy compose-related initialization work, regardless of the simplicity of the view inside compose.
Is there any way to reduce this time?

[Will Shelor]

I’d test it in a build with R8 on and debuggability off. In our testing, we found that it cut render time drastically. We wrote this article a few weeks ago- it has some tips that might be relevant for improving time.

[Adib Faramarzi]

I actually have. The production is way faster, but still not fast enough. It has a very noticeable impact on performance.
Thanks for the article, I'll give it a read.

[Will Shelor]

Our team has switched almost exclusively to Compose now, and find the performance in our production builds to be pretty close to well written XML most of the time. When it’s not, it’s often because we’re doing something wrong (like business logic in the Composable, or frequent recomposition)

[Adib Faramarzi]

Is that the same for older phones?

[Will Shelor]

JIT compilation will also hit you on local builds, even with R8 and debuggability off. I think it’s worth noting that initial composables take a bit longer to render. But there isn’t a ton of magic here, I’ve found it valuable to profile the app and see what is taking up the time. 🙂

[Will Shelor]

yeah! My experience was that older devices actually fare slightly better because JIT compilation only hits Android 7+- it’s precompiled on those devices, so it’s easier to see performance in line with what the end user sees.

[Adib Faramarzi]

I misread your first comment. You said to turn "off" R8?

[Adib Faramarzi]

that's weird

[Will Shelor]

sorry, I mistyped it

[Will Shelor]

have R8 on

[Adib Faramarzi]

Oh okay

[Adib Faramarzi]

That's what I already have

[Will Shelor]

edited for clarity. 🙂

[Will Shelor]

R8 made a really big difference in our testing

[Adib Faramarzi]

I'm testing on the final production build on an older build
Having a simple fragment with setContent on compose seems to be very noticeable unfortunately.

[Adib Faramarzi]

And this is true for every single fragment afterwards

[Will Shelor]

There is an initial hit of about 200 ms on my slowest device to create the composer. However, it shouldn’t hit subsequent fragments. It might not be a bad idea to run it with the profiler on and see what is taking the time.

[Adam Powell]

https://ui.perfetto.dev is the tool we usually use to investigate performance. If you have a specific pathological repro case please report it on the bug tracker and we'll take a look

[Adib Faramarzi]

Thanks. I’ll give it a look 👍