Hi guys. We currently migrating from views to compose and recently encountered a strange performance...

# compose

[Semyon Zadorozhnyi]

Hi guys.
We currently migrating from views to compose and recently encountered a strange performance issue
We have viewpager2 with two fragments. We decided to migrate one of the fragments to compose by setting ComposeView to it. Each fragment takes the whole screen.
The old screen is loading fine but as soon as you trigger creation of the second fragment (with compose view). Screen hangs for ~600ms

All consequent switches are working fine (under 16ms)

Details inside

[Semyon Zadorozhnyi]

systrace show that there are multiple recomposition happens
(systrace length 540ms)

[Semyon Zadorozhnyi]

We tried:
а) Switch content to something simple - even Text composable hangs
b) Disable all ViewPager animations and smooth scrolling - no improvements

[Semyon Zadorozhnyi]

Compose view creation inside fragment follows off. guides
Only addition is dagger component but systrace reports fast initialization

[Semyon Zadorozhnyi]

Loading and recomposition in release build take a little bit less time, but it’s still noticeable

[Albert Chang]

Looks similar to the conclusion of this article.

The first time we load compose has a one-time cost, even if navigating to different screens. As mentioned above, Compose has a global scope that initializes on the first render, contributing significantly to its launch time.

[adjpd]

I didn't think the delay would be so great, however.

I could recommend making a simple Android app with the recycler view and simple compose view to see if it is the same.

I'd appreciate it if you did that, and shared to code, so we could have a look.

[Zach Klippenstein (he/him) [MOD]]

Also, are you building in debug or release mode? Debug is known to be a lot slower at runtime