Rework measureRepeated to be based on coroutines [389149423]

Assigned

Feature Request

Status Update

No update yet.

Description

cc...@google.com

created issue #1

Jan 10, 2025 10:38PM

Currently, there are several problems with the architecture of BenchmarkState/BenchmarkRule:

BenchmarkState has extremely complex state management due to attempting to expose a single keepRunning API
Trace capture happens within BenchmarkRule instead of measureRepeated (to allow it to support the Java API)
Yielding the main thread from within measureRepeatedOnMainThread() is awkward, and happens within the measurement loop
sleep after thermal throttling is detected doesn't yield, so can cause ANRs with measureRepeatedOnMainThread (b/311242861)
configuration (e.g. profiler, metric type, looping behavior) and data output (json, instrumentation results, traces) are distributed, and not easily simplified (ideally measureRepeated would return all of this data)

This bug tracks an effort to rewrite much of the top level control flow of BenchmarkRule / BenchmarkState to be based on coroutines, and address all the above problems.

Comments

ap...@google.com <ap...@google.com> #2Jan 16, 2025 09:18PM

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

cc...@google.com <cc...@google.com> #3Jan 16, 2025 10:06PM

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

ap...@google.com <ap...@google.com> #4Jan 28, 2025 06:41PM

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

gr...@google.com <gr...@google.com> #5Feb 11, 2025 11:39AM

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

Issue 389149423

Description

Issue summary

Comments

ap...@google.com <ap...@google.com> #2Jan 16, 2025 09:18PM

cc...@google.com <cc...@google.com> #3Jan 16, 2025 10:06PM

ap...@google.com <ap...@google.com> #4Jan 28, 2025 06:41PM

gr...@google.com <gr...@google.com> #5Feb 11, 2025 11:39AM

Add comment

Issue metadata