You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
analyzer_benchmark should run on only one configuration #124065
This benchmark is bimodal because some of the Linux hosts have 8 cores and others have 4 cores. The bimodal nature of the benchmark means that SkiaPerf generates spurious reports and/or masks real regressions. Instead the benchmark should be pinned to a single configuration.
As a separate issue, I think this benchmark does not need a phone attached, but I'm not 100% sure about that.
This benchmark is bimodal because some of the Linux hosts have 8 cores and others have 4 cores. The bimodal nature of the benchmark means that SkiaPerf generates spurious reports and/or masks real regressions. Instead the benchmark should be pinned to a single configuration.
Yeah, we have two types of devicelab bots: 4 cores and 8 cores. Which do you want to enforce?
As a separate issue, I think this benchmark does not need a phone attached, but I'm not 100% sure about that.
Validated it works on a vm bot, but the benchmark is much slower:
Is it possible to specify a bigger VM instance so that the slowdown isn't so big? Either way, let's try moving to a VM and get a sense for whether that's a problem.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
keyonghan commentedon Apr 3, 2023
Yeah, we have two types of devicelab bots: 4 cores and 8 cores. Which do you want to enforce?
Validated it works on a vm bot, but the benchmark is much slower:
https://luci-milo.appspot.com/raw/build/logs.chromium.org/flutter/led/keyonghan_google.com/bd8e22d53a5c66633fa991eae3552f5d71c82c6e0c6cfcdadc73160cb5f8687c/+/build.proto
Do we not care about the number, but just the trend? If not, then we can switch it to the vm if a new trend series sounds okay.
zanderso commentedon Apr 4, 2023
Is it possible to specify a bigger VM instance so that the slowdown isn't so big? Either way, let's try moving to a VM and get a sense for whether that's a problem.
keyonghan commentedon Apr 4, 2023
A 32-core VM gives relatively lower metrics, though not that much:
#124147 to move it to a 8-core fleet as
bringup: true.github-actions commentedon Apr 21, 2023
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.