Obsolete
Status Update
No update yet.
Comments
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 17d1f80b6b6f8040363fbbb1d728d8e4fbe8a4c0
Author: Chris Craik <ccraik@google.com>
Date: Thu Oct 28 10:38:41 2021
Use more standard Perfetto buffer behavior
Bug: 199324831
Bug: 204448861
Test: TrivialStartupBenchmark # metrics still work, trace size consistent
Relnote: "Reduce chances of dropped data, and lower memory overhead from tracing"
As recommended by Perfetto team, switch to more standard buffer behavior:
- Smaller per-cpu ftrace ring buffers, which dump into single larger buffer
- Dump data to disk when central buffer full, so shouldn't drop data in long running (e.g. scrolling) benchmarks
- Add flushing to main buffer, so trace processor works in batches on very long traces
Change-Id: Id254422b83525f9d87a6bd359e2723601b510ab5
M benchmark/benchmark-common/src/main/java/androidx/benchmark/perfetto/PerfettoConfig.kt
https://android-review.googlesource.com/1874059
Branch: androidx-main
commit 17d1f80b6b6f8040363fbbb1d728d8e4fbe8a4c0
Author: Chris Craik <ccraik@google.com>
Date: Thu Oct 28 10:38:41 2021
Use more standard Perfetto buffer behavior
Bug: 199324831
Bug: 204448861
Test: TrivialStartupBenchmark # metrics still work, trace size consistent
Relnote: "Reduce chances of dropped data, and lower memory overhead from tracing"
As recommended by Perfetto team, switch to more standard buffer behavior:
- Smaller per-cpu ftrace ring buffers, which dump into single larger buffer
- Dump data to disk when central buffer full, so shouldn't drop data in long running (e.g. scrolling) benchmarks
- Add flushing to main buffer, so trace processor works in batches on very long traces
Change-Id: Id254422b83525f9d87a6bd359e2723601b510ab5
M benchmark/benchmark-common/src/main/java/androidx/benchmark/perfetto/PerfettoConfig.kt
cc...@google.com
I reviewed a bunch of these today, and I don't see any especially alarming patterns.
Few things of note:
- Most of these numbers track pretty closely
- Angler (API 23) doesn't track p50 (which may have confused me, maybe I was visually comparing lowest of both?)
- I think GPU time was actually added to tracking in API 31, which is why many of our numbers track pretty closely.
- Sailfish (API 29) has reduced variance in P95 of new metric, vs old (this looks to be because device is fast enough to hit significant aliasing, so will e.g. bounce between 7, 7.5, and 8
example query - Angler (API 23) has increased variance in P95 of new metric, vs old.
That last item was the only problem I noticed, but we should investigate.
cc...@google.com
Not able to repro the API 23 P95 gap locally.
I verified it's not an issue with new metrics dropping/missing trace content - we see the same number of frames (added logging locally). Unfortunately can't look at CI logcat, due to blocking bug - that would help us look at iteration data in more detail.
TrivialListScrollBenchmark_start[compilation=None]
frameTime90thPercentileMs min 9.0, median 9.0, max 10.0
frameTime95thPercentileMs min 10.0, median 11.0, max 12.0
frameTime99thPercentileMs min 20.0, median 22.0, max 26.0
totalFrameCount min 304.0, median 307.0, max 308.0
totalFrameCount1 min 304.0, median 307.0, max 308.0
frameCpuTimeMs P50 7.0, P90 8.9, P95 10.0, P99 23.0
Description
This may be because trace is dropping content near the beginning, which is generally more likely to jank. Will see if periodic write to disk fixes this.
Some of this (on more recent platforms) could also be that dumpsys metrics do account for GPU time on recent platform versions, and our metrics don't (for consistency across platform versions, as old platforms don't trace that).