Fixed
Status Update
No update yet.
Comments
ra...@google.com
ra...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit adc821747c2a7f56b6708344dcb0dcc1c5707c90
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Tue Apr 26 13:55:46 2022
Workaround compilation reset unavailable on user builds
* cmd package compile --reset does not work on user builds.
* To work around this, we copy the apk to the tmp directory, and then kick off an un-install and a re-install.
* A side-effect of uninstalling / re-installing is that ART profiles end up in vfy, which is the state we expect.
* Added `compilation.enabled` as an instrumentation test argument, to disable this behavior if the benchmark wants
full control on CompilationModes.
Test: SmallListStartupBenchmark
Fixes:
Bug:
Relnote: "Fixed an issue where compiled methods were not correctly being reset between each macrobenchmark on unrooted builds. This unfortunately requires reinstalling the apk each iteration, which will clear application data for each macrobenchmark."
Before:
SmallListStartupBenchmark_startup[startup=COLD,compilation=None]
startupMs min 198.5, median 210.5, max 222.6
timeToInitialDisplayMs min 196.6, median 208.0, max 220.5
SmallListStartupBenchmark_startup[startup=COLD,compilation=BaselineProfile]
startupMs min 190.7, median 205.3, max 212.2
timeToInitialDisplayMs min 188.8, median 202.2, max 210.3
After the change:
SmallListStartupBenchmark_startup[startup=COLD,compilation=None]
startupMs min 223.9, median 230.1, max 243.8
timeToInitialDisplayMs min 222.1, median 228.3, max 242.0
SmallListStartupBenchmark_startup[startup=COLD,compilation=BaselineProfile]
startupMs min 205.2, median 213.5, max 228.7
timeToInitialDisplayMs min 203.3, median 211.7, max 227.0
Change-Id: I31c740019640da0d0913066bb9ac59ab5c2a9627
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkScope.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/CompilationMode.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Arguments.kt
https://android-review.googlesource.com/2076902
Branch: androidx-main
commit adc821747c2a7f56b6708344dcb0dcc1c5707c90
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Tue Apr 26 13:55:46 2022
Workaround compilation reset unavailable on user builds
* cmd package compile --reset does not work on user builds.
* To work around this, we copy the apk to the tmp directory, and then kick off an un-install and a re-install.
* A side-effect of uninstalling / re-installing is that ART profiles end up in vfy, which is the state we expect.
* Added `compilation.enabled` as an instrumentation test argument, to disable this behavior if the benchmark wants
full control on CompilationModes.
Test: SmallListStartupBenchmark
Fixes:
Bug:
Relnote: "Fixed an issue where compiled methods were not correctly being reset between each macrobenchmark on unrooted builds. This unfortunately requires reinstalling the apk each iteration, which will clear application data for each macrobenchmark."
Before:
SmallListStartupBenchmark_startup[startup=COLD,compilation=None]
startupMs min 198.5, median 210.5, max 222.6
timeToInitialDisplayMs min 196.6, median 208.0, max 220.5
SmallListStartupBenchmark_startup[startup=COLD,compilation=BaselineProfile]
startupMs min 190.7, median 205.3, max 212.2
timeToInitialDisplayMs min 188.8, median 202.2, max 210.3
After the change:
SmallListStartupBenchmark_startup[startup=COLD,compilation=None]
startupMs min 223.9, median 230.1, max 243.8
timeToInitialDisplayMs min 222.1, median 228.3, max 242.0
SmallListStartupBenchmark_startup[startup=COLD,compilation=BaselineProfile]
startupMs min 205.2, median 213.5, max 228.7
timeToInitialDisplayMs min 203.3, median 211.7, max 227.0
Change-Id: I31c740019640da0d0913066bb9ac59ab5c2a9627
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkScope.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/CompilationMode.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Arguments.kt
Description
`workManager.getWorkInfosForUniqueWorkLiveData(TAG)`
The pain point with this is that this gives you all the completed workers' workInfos as well. If the intention is only to observe the status of the currently running workers, it requires a call to pruneWork() which seems like an anti-pattern. A work around with the current apis would be to create unique tags for each work but then again that's a pain to maintain if you have a complicated use case.
What I propose is a builder method along with this api to be able to put in simple filters like status of the worker(BLOCKED, ENQUEUED, RUNNING, SUCCEEDED) to begin with. Have got a thumbs-up from Rahul Ravikumar from the Toolkit team on this.