Status Update
Comments
cc...@google.com <cc...@google.com> #2
Thanks for your detailed post.
However, benchmark build type is under configured: at least isProfileable is not set to true for existing build type, probably there's more.
We should set isProfileable = true
by default when overriding an existing benchmark build type.
This issue is not about some specific configuration flag, but the general approach of dealing with external configuration. As a developer adopting baseline profiles, it seems extremely risky to me using a custom configuration due to how it's applied under the hood and the fact it may break default configuration.
I agree that is not great but this is a little tricky to do. For custom baseline profile build types we override all the properties. For benchmark I left it open to configure but it's mostly about these 2 properties:
isMinifyEnabled
isShrinkResources
I don't have a way to see if the user is setting them before overriding, so for this reason, I'd prefer not to. I agree with you that some other properties could be set by default to make this easier, i.e.:
isJniDebuggable = false
isDebuggable = false
isProfileable = true
The reason why I mentioned the release signing config in the beginning is because I want to use debug signing config.
In the specific of your issue, i.e. using a debug certificate can you override the benchmark and baseline profile setting? You should be able to do something like:
android {
buildTypes {
release { ... }
debug { ... }
benchmarkRelease {
...
signingConfig signingConfigs.debug
}
nonMinifiedRelease {
...
signingConfig signingConfigs.debug
}
}
}
cc...@google.com <cc...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Albano <
Link:
Added override for debuggable and profileable for benchmark builds in bpgp
Expand for full commit details
Added override for debuggable and profileable for benchmark builds in bpgp
Test: ./gradlew :benchmark:benchmark-baseline-profile-gradle-plugin:test
Bug: 369213505
Relnote: "isProfileable is always overridden in benchmark builds,
and isDebuggable is also now always overridden in both benchmark and
nonMinified (baseline profile capture) builds."
Change-Id: I487fa71083921682173f04fcbb477be5baf165f8
Files:
- M
benchmark/baseline-profile-gradle-plugin/src/main/kotlin/androidx/baselineprofile/gradle/apptarget/BaselineProfileAppTargetPlugin.kt
- M
benchmark/baseline-profile-gradle-plugin/src/test/kotlin/androidx/baselineprofile/gradle/apptarget/BaselineProfileAppTargetPluginTest.kt
Hash: 1906bbe52ba7ccb9ca0e1c1d6de33e7c91b5c6f0
Date: Fri Oct 11 10:07:06 2024
cc...@google.com <cc...@google.com> #4
I've landed a change that will set the following properties also when the benchmark build type already exists:
isJniDebuggable = false
isDebuggable = false
isProfileable = true
As well as the following for agp 8.0:
isDebuggable = false
I'm going ahead and closing this - if you've further questions please answer here and will reopen. Thanks.
ap...@google.com <ap...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-baseline-profile-gradle-plugin:1.4.0-alpha04
jo...@google.com <jo...@google.com> #6
Since release signing config is used by default instead of debug
is not mentioned in release notes - maybe this is a bug?
Cause the last time I found it mentioned in the release notes was in version 1.1
signingConfig.debug is used as the default signing config (
) b/153583269
So, if the switch to the release one indeed happened - maybe it's an issue?
ap...@google.com <ap...@google.com> #8
Branch: androidx-main
commit 6ae6408d8845038d1982cfc26b282939fdcebf18
Author: Chris Craik <ccraik@google.com>
Date: Mon Dec 04 16:30:20 2023
Disable method tracing by default on API 31+
Bug: 303660864
Bug: 303686344
Test: Compose benchmarks with multiple ART mainline versions
As the method tracing bug known to affect API 34 has been backported
to older releases via mainline updates, conservatively avoid method
tracing by default on all potentially affected devices (Android 12+).
Ideally we'd check against the versions known to cause the regression,
this is the simpler immediate fix.
Change-Id: I6b01006fc48e9d3bdec99ed2c22b5d424ae7e492
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/BenchmarkStateTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Arguments.kt
na...@google.com <na...@google.com> #9
@chris is this bug fixed?
ap...@google.com <ap...@google.com> #10
Branch: androidx-main
commit d592fecfc81fc38de896124a34d75a1b78da3d7f
Author: Chris Craik <ccraik@google.com>
Date: Mon Dec 11 10:31:13 2023
Disable method tracing by default, everywhere
Test: VectorBenchmark # API 30
Test: BenchmarkStateTest
Bug: 313868903
Bug: 303660864
We've observed that method tracing regresses performance in subsequent
benchmarks on at least API 29/30 without mainline updates (as they
aren't supported).
This change simply disables method tracing as the default while we
sort out in which situations it's safe to enable it.
Change-Id: I7b86146c22ac2fbfcd47cb64638c684d85161acb
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/BenchmarkStateTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Arguments.kt
cc...@google.com <cc...@google.com> #11
Marking as fixed since the default is now working correctly, filed
ap...@google.com <ap...@google.com> #12
Branch: androidx-main
commit 625c86746fb820045d8dca4180f4d880b4b0492b
Author: Chris Craik <ccraik@google.com>
Date: Wed Jan 17 17:02:28 2024
Set upper bound for method tracing workaround
Bug:303660864
Test: Verified method tracing still bypassed prior to mainline update
Change-Id: I648793bb789d16edbaec67fa5a0fcd5f51feeeb1
M benchmark/benchmark-common/src/main/java/androidx/benchmark/DeviceInfo.kt
pr...@google.com <pr...@google.com> #13
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-common:1.3.0-alpha01
cc...@google.com <cc...@google.com> #14
This isn't fully addressed - we noticed that the error for measurement after method tracing isn't on by default, working on a CL for that.
ap...@google.com <ap...@google.com> #15
Branch: androidx-main
commit 8f4d7d8e380dd1e374328fd5535f6d932e71b879
Author: Chris Craik <ccraik@google.com>
Date: Fri May 10 11:38:14 2024
Throw if measuments taken after method trace discards aot
Fixes: 303660864
Test: Ran SampleCustomBenchmark variant with 2 method traces sequentially, throw observed (mokey 34)
Relnote: "Microbenchmark will now correctly throw to prevent method
tracing from interfering with measurements. This occurs on certain
devices when method tracing is forced on (via instrumentation args or
MicrobenchmarkConfig), and if a measurement is attempted after a
method trace. Affected devices are running API 26-30 or certain ART
mainline module versions affected by this interference, and can be
detected at runtime via
`ProfilerConfig.MethodTracing.affectsMeasurementOnThisDevice`."
Change-Id: Iafb92c47c76bf257c047634b61401d873ce85cc5
M benchmark/benchmark-common/api/current.txt
M benchmark/benchmark-common/api/restricted_current.txt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/BenchmarkState.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/ProfilerConfig.kt
M benchmark/benchmark/src/androidTest/java/androidx/benchmark/benchmark/SampleCustomBenchmark.kt
pr...@google.com <pr...@google.com> #16
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-common:1.3.0-beta01
cc...@google.com <cc...@google.com> #17
Romain saw this on an API 35 device, reopened the ART bug, and marking this blocked on that.
ap...@google.com <ap...@google.com> #18
Project: platform/frameworks/support
Branch: androidx-main
Author: Chris Craik <
Link:
Fix method tracing affecting measurements when art built from source on API 34
Expand for full commit details
Fix method tracing affecting measurements when art built from source on API 34
Fixes: 303660864
Test: TrivialKotlinBenchmark (with duplicated benchmark on VP1A.230706.001)
Test: DeviceInfoTest
Change-Id: Ic7cad122150c515779365d6565f1c62c69213f82
Files:
- M
benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/DeviceInfoTest.kt
- M
benchmark/benchmark-common/src/main/java/androidx/benchmark/DeviceInfo.kt
- M
benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/Metric.kt
Hash: 4774190a430d12b3be4b2f3c8880334e2cf66a51
Date: Tue Jan 21 17:04:10 2025
na...@google.com <na...@google.com> #19
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-common:1.4.0-alpha07
androidx.benchmark:benchmark-macro:1.4.0-alpha07
Description
Hi, We are facing an issue that if we run the whole ModifiersBenchmark class, we get different results from running each test individually. For instance, running the whole test class for Modifier on a Mokey device (with the clocks locked), the results are as seen in the attached snapshot (ModifiersBenchmark class run). However, running one test individually gives a different result. For example, running the base case alone gives the following result attached in the snapshot (ModifiersBenchmark individual run).
Relevant links: Trace files for base case when running the whole ModifersBenchmark class: Base Case class run
Trace files for base case when running the Base test only: Base Case individual run