Hey guys, maybe i found a performance issue in mix...

# compose

[Alexander Karkossa]

Hey guys,
maybe i found a performance issue in mixed compose/non compose app.

We tried to implement a detail view within a single activity (multiple Fragments) app as compose view. Everything works fine, but the the first contact to the "compose world" seems to be laggy. If you push the button to navigate to the detail compose view, there is a delay more or around one second. It feels not good. After these delay, you can navigate back and forwards to compose without delay until you restart the app. After restart, the same performance issue at first contact.

Maybe some "initial compose things" going on here?

[romainguy]

It’s complicated but a tl;dr is: you are likely running into something we’ve been tracking down which is the cost of JITing that Compose code

[romainguy]

That problem will “go away” as you’ve seen (and even more so if you stop updating the app for a few days as AOT will kick in during device idle maintenance)

[romainguy]

Views don’t suffer from this because they ship in a pre-optimized form on the device

[Alex Gabor]

Is this something that can be mitigated? Should it be less severe on release builds?

[Alexander Karkossa]

Sry don't get it :) Maybe too late....

I tried another app created as compose only. The compose only app has a similar problem but at the start. After starting the app, around one a second delay before any ui is visible. Maybe also issue?

[Alexander Karkossa]

startup delay.mov

[Adam Powell]

We're working on it. We've got a few things in flight on this, nothing major to share just yet

[Alexander Karkossa]

Anything that i can do to fix / workaround the first problem (Compose in a non compose app)?

My thought would be to rework the first view within the app as compose view also, to move the delay to the app start?

[dewildte]

I also keep running into random crashes coming from somewhere deep down in the rendering code. I keep getting SIG errors crashing my apps.

[Adam Powell]

@dewildte probably worth a separate thread 🙂

[Adam Powell]

@Alexander Karkossa yes, including a small ComposeView somewhere in an early screen can help, also otherwise starting up a headless recomposer/composition in the background of your app, though that won't exercise as much of compose-ui itself. We're playing around with some different strategies, their impacts, and how to best package it

[romainguy]

@Alex Gabor It will be less severe on release builds if you use R8, just by virtue of various optimizations. But the real benefit will come from the AOT pass that will happen after using the app and letting the device perform that compilation step. Like Adam said it’s something we’re working on as we speak 🙂