IssueTracker

In Compose' SmallListStartupBenchmark COLD startup, library baseline profiles are close to Full compiled performance, and clearly better than None, e.g. on API30. Same pattern with the View version.

This holds true across all monitored API levels (26, 29, 30, 31) with that benchmark.

However we see a weird pattern with the TrivialStartupBenchmark - the clear order (from best to worse) is Warmup, None, Baseline Profile, Full. E.g. on API30, though this doesn't hold on API26/28 where everything that's not warmup is pretty clustered together.

This exact same pattern is visible for IoSettingsActivity on API30. While that activity has UI, it looks to be an ~empty first frame, with content showing up later (not tracked by the benchmark since it doesn't report fully drawn).

And for Wear's Startup Benchmark e.g. on API30, which has nearly empty UI.

Are these trivial benchmarks punished/paying for loading compiled code they don't use? If so, should we rework these to be more useful, and more closely match actual UI with real content to display? We probably only need one empty activity benchmark, maybe one each for compose/view.

It may be that this hits Compose much harder, since it will AOT compile a lot more than a view equivalent trivial Activity. Note that the APKs themselves are big enough with multiple activities, so R8 shouldn't be expected to just remove most of Compose.