Status Update
No update yet.
Comments
cc...@google.com
ChromiumPerf/mac-m2-pro-perf/blink_perf.css/NestingIdentInvalidValue/NestingIdentInvalidValue.html
Verification workflow id: projects/62121018386/locations/us-central1/workflows/sandwich-verification-workflow-prod/executions/a6b905ed-9343-4d2b-a994-55556a5aa8bd
dv...@gmail.com
reproduced the regression with statistic: {'control_median': 13.009999999962748, 'lower': 10.344712166063431, 'p_value': 1.862645149230957e-09, 'treatment_median': 14.409999999776481, 'upper': 11.095673438085797}.
Proceed to bisection.
dv...@gmail.com
Created by chromeperf@appspot.gserviceaccount.com
Benchmark: blink_perf.css
Story: NestingIdentInvalidValue.html
Measurement: NestingIdentInvalidValue
The job has been scheduled on the "mac-m2-pro-perf" queue which currently has
1 pending jobs.
cc...@google.com
ChromiumPerf/mac-m2-pro-perf/blink_perf.css/NestingIdentInvalidValue/NestingIdentInvalidValue.html
To opt-out of further automatically started bisections for this issue, please
add the <b>Chromeperf-Auto-BisectOptOut</b> label.
dv...@gmail.com
<b>Started sandwich culprit verification process.</b>
culprit verification workflow keys: ['projects/62121018386/locations/us-central1/workflows/sandwich-verification-workflow-prod/executions/9c581e78-2703-4ec8-b526-034708263113']
dv...@gmail.com
<b>Updating trunk VERSION from 7111.0 to 7112.0</b> by chrome-official-brancher@chops-service-accounts.iam.gserviceaccount.com
NestingIdentInvalidValue: 12.99 → 14.37 (+1.39) (+10.7%)
Understanding performance regressions:
Benchmark documentation link:
You can view the full results and re-run the Pinpoint job at:
If you think Pinpoint blamed the wrong commit, please add issue to
`Chromeperf-CulpritDetection-NeedsAttention` (hotlist:5670048) and
unassign yourself so that a sheriff can help diagnose.
cc...@google.com
Did the tracing buffer increase improve the problem?
Where can I get this project source code ? androidx.benchmark:benchmark-macro
Here:
or mirrored on github:
If you want to experiment with different perfetto capture configs you can also use this API:
dv...@gmail.com
thank you
dv...@gmail.com
I have a question about perfetto command.
as I found that, the data sources wasn't started after just run the perfetto command so I want to use --background-wait options, to let perfetto wait data sources started , then return.
I also worry about perfetto command process would killed by lmk, so I want to use detach mode to run perfetto, but --background-wait and detach mode are mutually exclusive.
how to achieve my goal: 1、return until all data sources start, 2、 run in background
la...@google.com
If perfetto is started from an adb shell, it cannot be killed by LMKD. So you can safely use --background-wait without worrying.
--detach is realy reserved exclusively for the System Tracing app and should not be used by others.
dv...@gmail.com
dv...@gmail.com
thank you
dv...@gmail.com
It works after enlarge the buffer size and always use --background-wait option
( I have used wsl in windows , following the directions in
Thank you.
by the way, is there better way to simulate high system loads in android during benchmark test?
ap...@google.com
Branch: androidx-main
commit 2bb16072e48a70b44cb208b2c13dbecb79ce66f3
Author: Chris Craik <ccraik@google.com>
Date: Mon Mar 18 14:48:22 2024
Use --background-wait on API 33+
Bug: 310760059
Test: ./gradlew bench:b-m:cC
Test: manually confirmed API 33 has --background-wait, 32 does not
Relnote: "Enable blocking start on Perfetto trace record to reduce
risk of missing data at beginning of trace. Only supported on API
33+."
Change-Id: Ie6e417ad248b431ebf6096e2865265d51553be7f
M benchmark/benchmark-common/src/main/java/androidx/benchmark/perfetto/PerfettoHelper.kt
Description
Component used:MacrobenchmarkRule Version used:1.20 Devices/Android versions reproduced on: OPPO Find N3
If this is a bug in the library, we would appreciate if you could attach:
As proper marcrobenchmark， I dedicated to find out the user perceived janks.
According to some studies, it should be more than 5 consecutive jank frames, or a single jank frame that's more than 5 frames time.
And I add some loads during macrobenchmark testing.
however, when I add some loads(for example, let some app running in background, the system becomes slow, the perfetto command started /stoped by macrobenchmarkrule can't capture the full perfetto trace which happens between measureBlock.
I checked trace, found perfetto command started by macrobenchmark running in little cpu cores. That maybe the cause for the loss of perfetto trace during high system loads.
I still found that, If I keep a perfetto trace running outside macrobenchmark, It merely happens that losing the traces during marcobenchmark ?
can you fix that?