I’m experiencing some performance issues when usin...

# compose

[Ricardo García]

I’m experiencing some performance issues when using accompanist pager in conjunction with a LazyColumn for each one of the pages. Scrolling is noticeably laggy. I thought at first it was related to having a ConstraintLayout for each item in the LazyColumn, but I still see the same issue when using a simple Column/Row layout instead of a ConstraintLayout. Is this a known issue?

[Ricardo García]

I’m on 1.0.0. On high end devices, the scrolling lag goes away after some interactions (few scrolls + opening the tabs). While on lower end devices, the lag never goes away

[Ricardo García]

CC @cb

[Stylianos Gakis]

Have you tried a release build? Debug builds with compose are definitely a bit more choppy.

[Ricardo García]

Release build perform better than debug build, but the lag is still noticeable

[Will Shelor]

Does your release build use R8? In our testing, R8 made it significantly faster as well. The scrolling delays are probably the JIT compiling of Compose code, which will be a little better when delivered from the play store, and will be better in subsequent sessions. There are things that might be able to speed it up, but before taking too much time it might be worth running through it with the Android Studio profiler to make sure there isn’t something else causing the slowdown (I thought one of our Composables was slow, but it turned out we had some sorting that was taking a long time)

[Will Shelor]

As a side note, if you want to speed up this specific thing, it would probably be a good candidate for Jetpack ProfileInstaller, to skip the JIT compilation of some of your more complex composables. It’s a very new utility, though, and documentation is scarce. (We’re playing with it now, hoping to do a writeup once we’re more familiar with it!)

[Ricardo García]

@Will Shelor It does use R8. I’ve been profiling the app but the slowdown seems to be coming from compose. I’m gonna check out the ProfileInstaller to see how it would fit here. Very nice post btw

[Will Shelor]

Thanks! I think Compose is really awesome and I’ve enjoyed diving into it… but it is definitely a little bit slower than XML. Shouldn’t be insurmountable, though- there might be something else going on. I’m working on another post about tricks we’ve been finding to improve performance, but so far the most significant ones probably don’t effect what you’re talking about. It might be worth diving into tagging composables that can be reused, moving your Composable out of XML (if possible, if it’s already pure Compose this won’t be a thing), and trying out a few things to simplify your layout. You might also be able to tweak something in the pager- it’s possible that it’s doing things you don’t need. We copied their bottomsheet over to add custom behavior, and I found it to be quite easy to work with (and I learned a ton about Compose while doing so)

[fabio.carballo]

out of curiosity, do you have any suggestions or tips on how to profile if your composable is recomposing too many times? Im facing the laggy situation, but cant be sure is the compose performance problems or something im doing.

[Stylianos Gakis]

I would try it with a release build and see how it performs there. If there’s problems with the minified version, then there’s absolutely (unless there’s some internal bug?) something that you can improve. That’s how I’ve approached it.
And the classic SideEffect { Timber.d("Look ma! I am recomposing!") } if I am curious how ofter my current composable recomposes and if it does way too often it becomes obvious.

[fabio.carballo]

ahah great advice actually 😄 thanks a lot.

[Will Shelor]

There are a few things we’ve learned in the last 2 months about reducing recomposition and making things work in general faster. The idea of using a SideEffect to identify recomposition is a great one! If you’re seeing jank, you should also run the profiler to see if there are any unexpected calculations done in your composable (it should usually be performing 0 business logic on recomposition). There are also instances where you can give your lazy columns and lists unique keys to help them reduce recomposition (especially if elements move!). Aas a side note, ProfileInstaller reduced our composition by about 20% further- but I think we’ve landed at “we probably recommend using it, because it basically does the same thing that installing the play store does and it’s very possible to make your app larger than it needs to be- just know that the performance when installed might be even better than it is when testing”

[fabio.carballo]

this is great insights - did you found any guide about the profile installer?