Status Update
No update yet.
Comments
ng...@google.com
ap...@google.com
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
ma...@google.com
ra...@google.com
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
cc...@google.com
This bug is for the behavior in macrobenchmark and the workaround.
The issue of opening up that behavior is being tracked at
cc...@google.com
This fix made all compilation=none and compilation=warmup measurements slower in CI
E.g. androidx.compose.integration.macrobenchmark.SmallListStartupBenchmark_startup_startup_COLD_compilation_None_ went from 340 -> 380ms.
As these were rooted devices, this indicates --reset (done in our rooted CI) does not put the device into the same state as fully reinstallation (after CL landed).
cc...@google.com
Filed
cc...@google.com
Note from perf gap investigation in
sh...@gmail.com
ra...@google.com
Unfortunately it's not possible to just clear ART profiles prior to Android T on user builds. This is why we need to re-install the APK.
On the next iteration of Macrobenchmark (1.2.0-alpha01), we will try and clear profile caches if the session is rooted.
sh...@gmail.com
be...@google.com
Android T is the development name for Android 13.
th...@gmail.com
"Resetting ART profile caches isn't allowed on user (non-rooted) builds. To work around this, androidx.benchmark:benchmark-macro-junit4:1.1.0 includes a fix that reinstalls the app during the benchmark (issue)."
When the docs say a "fix that reinstalls the app during the benchmark", and in the above comment, where you talk about 'clearing application data for each macrobenchmark', I just wanted to be clear this relates to running benchmarks only. It does not mean that when we upload our baseline profile with our APK version for the first time, our users will lose their application data? I'm new to this area of development so thanks for patience with the potentially rudimentary enquiry...!
ml...@google.com
The app data is cleared only when running the Macrobenchmark locally on the device as part of the verification/generation process. No action is done to either the published app, or to apps on other devices.
When you upload the baseline profile with the APK/AAB, it's already in the generated (binary) form and it won't clear any user data.
Description
Macrobenchmarks needs to clear ART profiles between runs to ensure a clean slate before a measurement.
However, calling
cmd package compile --resetis not supported on user builds at all. This means, that we can't actually rely on--reset.Additional context: