One Off the Slack: Performance: It's Getting Beta

Orhan Tozan asked:

Compose Beta is expected to release soon. People that already are using Compose, how is the performance compared to the Android View system?

The immediate responses, from a handful of Compose UI users, is that Compose UI performance is generally below that of equivalent UIs created using the classic View system.

In response, Google’s Adam Powell called for test cases and outlined what Google’s plans are in the coming months:

Please send us example code for cases that don’t perform as well as you would expect or like via the issue tracker and we can turn them into test cases to analyze and chase before 1.0. We’re currently tracking performance work in the following areas:

Composition itself: in this area we’re looking to separate and simplify the process of initial composition vs. updates, which should lead to less branching code and higher performance. We also have some tuning to do of some of the internal composition data structures. Some of you have noted the experimental multithreading API as well, which will get composition off the main thread and allow for different elements to [re]compose concurrently or on different threads altogether - think different lazy list items in parallel. Many low-end Android devices have several low-powered CPU cores available that this can take advantage of.

Measure and layout: in our current benchmark dashboards this is all in pretty good shape and generally outperforming views. We’re pretty happy with this, as it bears out the changed measure/layout APIs from views, where views had previously hit a ceiling from not having enough information to work with during relayout and layout invalidation.

There are, however, a number of cases where our initial layout modifier APIs that have been around since early alphas force a return to recomposition to change things rather than relayout alone. You can see this in some of the offset modifiers - note that the newer variants accept lambdas and not direct sizing or offset parameters - this allows us to skip composition entirely and work only in layout when snapshot state read in those lambdas change.

Lazy lists and scrolling performance there are an area of active investigation. The folks working on these components have been on the bleeding edge of some other composition infrastructure work we’ve been doing, and some more performance optimizations are yet to come there.

(This is one we know is critical for all of you and it’s getting a lot of attention; some of the supporting work is pretty deep in the stack and so it’s taken some time.)

The team has largely prioritized API stabilization for the past few months to try to reduce the churn all of you feel when we update from release to release, so that it’s easier for you all to stay up to date. The lambda-based modifiers are one example of this where we’ve set things in place to optimize performance at that API level, even though in some cases the actual optimizations themselves haven’t been implemented yet

But we really would love specific test cases from you all! It’s hard for us to unlearn the things we know about the system to write test cases that are representative of what people try first without that deep context in their heads, and we tend to write test cases that hit all of the happy paths without thinking about it. The more, the better!

Additionally, we do assume the kinds of optimizations r8 performs for release builds. If you’re not checking release builds with r8 optimizations enabled, please compare with that as well.

So, if you are working with Compose UI and see sluggishness that you are certain is not tied to your own code, the best thing that you can do is:

It is in all of our interests to get performance problems addressed in the coming months, before Compose ships a stable release and more developers start trying it “for realz”.

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!