Hi folks :wave:, This question is regarding bench...

# compose

[Aleon Q]

Hi folks 👋,

This question is regarding benchmarking composables in Jetpack Compose.
What I am interested in as a starter is to measure how long does it take to render a composable on a screen for the first time it is composed and on recompositions.
What I have tried so far:
• Android benchmarking samples from the official repo here.
• Looked at other initiatives that folks in the community have come up with like this repo here.
• I took suggestion from @romainguy on this thread , @Leland Richardson [G] on this thread and went about trying out how can I utilize some of the ideas there.
There are many good starting points for benchmarking in the compose repo. I found something that seems very relevant in tests for Text composable in TextBasicBenchmark that uses ComposeBenchmarkRule. It uses a few methods that benchmarks the first composition, measure, draw, layout. The problem I am running into is what how would I be able to use that ComposeBenchmarkRule? I couldnt find any dependencies/library that exposes this class. Is this currently available for use in any jetpack compose testing libraries? How should I go about it?

Thanks for creating this space and allowing the questions to be asked. Much appreciated 🙌

[Ben Trengrove [G]]

Our macrobenchmark sample includes Compose. Does that do what you need? https://github.com/android/performance-samples/tree/main/MacrobenchmarkSample

[Aleon Q]

Hi Ben, thanks for responding 🙌

Yeah, I took a look at the repo and couldnt find any test that measures the render time to draw, layout, measure, compose a composable.. May be I totally missed it. Would you be able to point me to a specific test if the samples have it?

[Ben Trengrove [G]]

Oh you are right sorry. I missed that you actually wanted to time the individual compose phases. I'll try to find out more info for you

[Aleon Q]

So much appreciated Ben..
I will edit my question to include that I looked at the benchmarking compose samples in the said repo. Sorry about that.

[Aleon Q]

Meanwhile, what I have been trying out is to explore the benchmark tests in Compose’s repo. I copied over the classes required for using the ComposeBenchmarkRule to my benchmark project and make some adjustments to gradle and copied code to make it compile. After some failed to compile or run iterations, I was able to benchmark a Composable. Still continuing on this path.

It works, in that it logs out the benchmark stats for the tests that I wrote but I am not sure if what I did is the correct way for the two reasons:
• Is there an easier way that I may have overlooked entirely
• Is this still the correct way after I ported over the code and made some adjustments to make it compile and run
I must say that I really appreciate:
• That the code is all open to be looked at, to learn from
• Most of the error messaging that I encountered during this exercise were right on the money because of which I was able to make some the adjustments that I did
Looking forward to some inputs /direction from the team on this.

Edit: Edited “errors” to “error messaging” in the last bullet point.

[Chuck Jazdzewski [G]]

Let me reaffirm what Romain said, the benchmark framework is our recommended way to benchmark compose applications. We have worked to make benchmarking your app both easy and as accurate as we can but benchmarking is never easy. It is what I use and I have worked with the benchmarking team to help improve it. It is where we reflect the our experience for collecting accurate benchmark numbers and it is what we use to benchmark Compose.

The benchmark framework has two modes, micro benchmarks and macro benchmarks. Micro benchmarks are most useful for shared libraries and utility functions, not for composition. I use it for benchmarking compose but I am testing the library directly, so, in a sense I am benchmarking compose as if it was a utility library. However, when I am looking for areas to improve compose I always start with a macro benchmark derived from a real application or a synthetic benchmark which does something inspired by a real world application.

As for "is this still the correct way" I cannot say. The best benchmarks are ones that are representative of real-world user experience and that differs for every application. If the results you are getting correspond to what you are seeing when using the application (the release version with R8 transformed and fully or profile compiled) it is a good benchmark. If it doesn't, you are probably not benchmarking the right thing.

[Ben Trengrove [G]]

We have filed a feature request for you as well, https://issuetracker.google.com/225122468

[Aleon Q]

Hi @Chuck Jazdzewski [G], so thankful for your response and insights.
I am looking to benchmark a few composables I wrote based on the points that I mentioned above. I made an aar out of the few classes taken out of the classes that I needed in compose’s repo (involving around ComposeBenchmarkRule) so that I wont have to copy over the classes of interest for every project that I want to use these type of benchmarks on. It seem to do the trick for me.
Also, I stumbled upon this thread where Leland and you very succinctly painted what performance improvement is.. glad to have found it..

That is so nice of you, thanks @Ben Trengrove [G] for creating the feature request. I just starred it. Hope it gets picked up by the team and be of value to others in the community as well.

🙌 🙌