Android per-CL bisect is very slow. |
|||
Issue descriptionLooks like the off late bisect script for Android is very slow, and the user are having trouble finding the culprits for the reqressions. Comments from the user "Seems like it's always super super slow when I run it. It takes seven or eight minutes to initialize when all it really needs to do is run binary search on a list of prebuilt APKs. Another annoying issue is that if for some reason the APK fails to download, instead of giving you a chance to plug/unplug your test device, reboot the ADB server, etc., it just aborts and makes you wait another seven or eight minutes to initialize again. I've run it three times now and it's failed to download the build every single time."
,
Jun 8 2018
Seems like the performance gets worse as there are more revisions in the range. This seems like it should be possible to fix.
,
Jun 8 2018
Yea that range is way too big. We usually to a version bisect with the same script first to narrow it down then do a per-cl bisect.
,
Jun 8 2018
Good to know. Of course the fact that you can do this means there's no fundamental reason why the script should be so slow for this case.
,
Jan 11
Available, but no owner or component? Please find a component, as no one will ever find this without one.
,
Jan 16
(6 days ago)
|
|||
►
Sign in to add a comment |
|||
Comment 1 by rlanday@chromium.org
, Jun 8 2018