A question about just one baseline-prof.txt(PR : #258)

[Veronikapj]

Hello team,

This is not an issue, but I have a question about this PR. If you can answer it, you can close it.

I understood that previous baseline profile files had to be created and placed in the directory src/baselineProfiles for each path where the profile was to be set. However, I see that only one file was left in this PR.

If I want to create a baseline profile for each path, should I create a profile file for each path and place it in src/baselineProfiles as before, or should I only keep one file? I would appreciate it if you could explain this in more detail.

[keyboardsurfer]

When using the baseline profile Gradle plugin you can automatically generate baseline profiles during release builds. You can choose to still keep them in src/baselineProfiles but it's not strictly necessary as it can be generated during the actual release process.

Any baseline profile files under src/baselineProfiles will be merged into a single baseline.prof and baseline.profm during aab / apk generation.

[keyboardsurfer]

A quick, one-off way is by opening the apk / aab in Android Studio's inspector and look for the baseline.prof file.

[VarenytsiaMykhailo]

A quick, one-off way is by opening the apk / aab in Android Studio's inspector and look for the baseline.prof file.

In my project, I don’t have any baseline-prof.txt files in the project files, but when I build the apk, I see baseline.prof and baseline.profm in it. How is this possible? Where do they come from in the APK?

And CompilationMode.Partial(BaselineProfileMode.Require) in my baseline-profile startup test doesn't throw exception.

[ChrisCraik]

Baseline profiles can either be included in apps directly, or in android libraries (in the .aars) so that apps using the library will get some of the compilation benefit. Many Jetpack libraries include these: https://cs.android.com/search?q=baseline-prof.txt&sq=&ss=androidx

So you should be able to open the baseline.prof in your apk, and from that be able to tell which libraries you're getting profiles from based on which classes and methods it contains.

Note though that profiles from libraries aren't as good as ones you're generating within your project for two big reasons:

1. they can only reference library code, so can't speed up any of your apps custom code
2. they're just guesses guesses at what library methods and classes are important to downstream consumers (often driven by sample usage scenarios that won't match your app perfectly)

As long as you're using a vaguely recent version of e.g. Compose, androidx.activity, or androidx.appcompat, you'll have some baseline profiles by default, but you won't see as big of a difference between CompilationMode.Partial(BaselineProfileMode.Require) and CompilationMode.None() without generating your own. How big of a gap you'll see between library and custom profiles will depend mostly on how much non-library code you're running.