Status Update
Comments
ra...@google.com <ra...@google.com> #2
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
ml...@google.com <ml...@google.com> #3
ra...@google.com <ra...@google.com> #4
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
ml...@google.com <ml...@google.com> #5
I have a feeling there's a lot of implicit behavior behind the startup/compilation modes, which is not easy for developers to discover or understand.
For example:
StartupMode.COLD
--> process dies betweensetupBlock
andmeasureBlock
while not in other modes- reinstalling the app on (older) user device builds
StartupMode.WARM
--> there's a additional warmup iteration
And now we'll build additional behavior that is different for StartupMode.COLD
.
ra...@google.com <ra...@google.com> #6
I understand your concern, but with the current shape of the API: we don't really have too many options to control this behavior.
Once the lower level APIs are available to write your own Macrobenchmark loop, you can do a lot more and define the bits exactly like you want. That being said, I also want to extensively document the lifecycle of a method trace better in Macrobenchmark.
ml...@google.com <ml...@google.com> #7
Ok, sounds good. Thanks for explaining!
cc...@google.com <cc...@google.com> #8
I have a feeling there's a lot of implicit behavior behind the startup/compilation modes, which is not easy for developers to discover or understand.
Agree, this is tracked in
And now we'll build additional behavior that is different for StartupMode.COLD.
This is a good point, and I agree we shouldn't be making StartupMode.COLD even more complex to reason about. I'd prefer we say method tracing is always on during the measurement in macrobenchmarks (assuming you use macrobench to start/kill the process), and we should make that work automatically.
ra...@google.com <ra...@google.com> #9
I'd prefer we say method tracing is always on during the measurement in macrobenchmarks (assuming you use macrobench to start/kill the process)
When a process is being started is not entirely obvious to an app developer. Additionally, method traces collected during startup are actually very important; so we need to make that part easy. Which is why startActivityAndWait(...)
signals a method trace start (when StartupMode.COLD
is being used), and the end of the measurement is when a method trace ends.
ml...@google.com <ml...@google.com> #10
What scenario do you have in mind that you'd want the method tracing for startup, but it wouldn't be covered by the startActivityAndWait
or measureBlock
?
If I have
startupMode = COLD
setupBlock= {
// prepare something
}
measureBlock = {
startActivityAndWait()
}
I would say I still want to only see the method trace of what I'm measuring.
If I have
startupMode = COLD
setupBlock= {
startActivityAndWait()
}
measureBlock = {
// do something in the app
}
This doesn't work, because the process is killed between setupBlock
and measureBlock
.
I can have something like
startupMode = COLD
setupBlock= {
sendABroadcastWhichWakesTheProcess()
}
measureBlock = {
startActivityAndWait()
}
But I would still expect the method trace to run in the measureBlock
?
The process would be killed after setupBlock
anyway, so the method trace can't really survive, can it?
Maybe I'm missing some scenario though.
cc...@google.com <cc...@google.com> #11
Summarizing an offline convo about how we plan to do this:
- at beginning of measure block:
- start method tracing if process alive
- (in measure block) process started
- start process with method tracing
- (in measure block) process killed
- flush method trace before kill
- at end of measure block:
- flush method trace
No special handling for startup modes, or tracing of the setup block.
This requires a lot of checking process state, but that should only happen while method tracing, so it's worth the cost to get predictable tracing.
Note that you'll potentially get arbitrary numbers of traces depending on how many instances of the process run sequentially.
ml...@google.com <ml...@google.com> #12
I think that SG. I think the arbitraty numbers of traces is fine, because these probably matter only for further analysis.
ra...@google.com <ra...@google.com>
ap...@google.com <ap...@google.com> #13
Branch: androidx-main
commit 81955ec73236d3862de4897aa4fa8ad53c453e89
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Fri Apr 12 15:10:25 2024
Improve lifecycle of a method trace in a Macrobenchmark.
* Previously, when method tracing was turned on for a Macrobenchmark, the trace session would start with a process cold start, and end at the end of a `measureBlock()`.
* This change makes it so that Macrobenchmark automatically attaches to the process to start a profiler or uses `start-profiler` under the hood when using `startActivityAndWait(...)`.
* Tracing starts correctly on process start inside a `measureBlock` or at the beginning of a `measureBlock` and therefore we always get a well scoped trace at the end.
Test: Added MacrobenchmarkScopeTest
Bug: 300651094
Relnote: Make it simpler to capture method traces for a Macrobenchmark is scoped to the duration of the actual `measureBlock()`. Previously, it started at target process launch and only supported cold startss
Change-Id: Iee85a37d5b03d92a3128c976b41bd145b2921161
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Profiler.kt
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/MacrobenchmarkScopeTest.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/Macrobenchmark.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkScope.kt
Description
When you enable method tracing for benchmarks, it's currently started with
startActivityAndWait
and it's disabled after the benchmark finishes.Method tracing collects huge amount of data which might result in big trace file and might take long due to its nature to slow down the app's performance.
This causes problems for scenarios navigating to a certain screen and starting collection from there. For example start the app, log in, navigate to a screen and scroll some content. The interested part is only scrolling the content.
There might be several options how this could work:
Enable method traces for
measureBlock
. This would be intuitive with when benchmarks actually record data.Have API to dynamically enable/disable method tracing. This might be helpful to record only part of the measure block. This could result in more polluted API though. What if you don't pass method androidx.benchmark.profiling.mode=MethodTracing`, but call the API?