Status Update
No update yet.
Comments
cc...@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
ap...@google.com
ap...@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
ap...@google.com
Branch: androidx-main
commit 74638b3f1fd47614a3655a7a911914c0d33d7ea7
Author: Chris Craik <ccraik@google.com>
Date: Mon Jan 29 15:26:05 2024
Create alternate frame timing metric, and fix unterminated frames
Bug: 322232828
Test: FrameTimingQueryTest
Relnote: "Fixes issue where unterminated frames at the beginning and
end of the trace could be paired together, which would incorrectly
report as a single extremely long frame."
Creates alternative frameDurationFullMs metric implementation, which
isn't yet used in FrameTimingMetric but can be used to account for
vsync intended delays on UI thread.
Also fixes an issue that became more visible when validating its
measurements in traces.
Change-Id: I393531f8cf983b2700c419c00a9c7c47ec382e67
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/perfetto/FrameTimingQueryTest.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/perfetto/FrameTimingQuery.kt
cc...@google.com
Bumping in priority after some discussions with +Andrew and +Leland.
We found that in CI, we saw fluctuations in both frame timing and frame overrun due to buffer stuffing periodically hitting Sargo API 31.
Periodically we'd see very large spikes in P90 frame timing because randomly more than 10% of interactions would hit triple buffering, and thus have an additional 16+ms of latency. I expect gfxinfo is less significantly affected since that's median of 90th percentile frame time across each iteration.
There's more to investigate though in instability in the other scenarios, however, and this noise from buffer stuffing is likely not the only issue.
I'd like to move us to something that accounts for buffer stuffing more generally, will file blocker bugs for improvements to perfetto frame timing metrics.
jj...@google.com
Would disabling triple buffering be an option here?
cc...@google.com
For app developer macrobenchmarks, that would be great. How do we do that? (ideally on user builds too)
Description
FrameTimingMetrichas a few issues that make it hard to align with user impact, from internal feedback/discussions:frameDurationCpuMsaccounts for the UI slice, but surprisingly doesn't account for any main thread delays from runnables that delay Choreographer#doFrame from starting. (This was an old decision to keep behavior consistent both pre 31 and post 31, when expected/actual frames were available, should consider revisiting.)frameOverrunMsdoes account for delays, but still treats runnables different from in-frame work, due to how out-of-frame runnable main thread delays will delay the expected frame in the frame timeline.