Do perf regression.

Removing Internals>VR component and assigning to Internals>XR

Bisect points to fcde2906f4890b7f2d68a9a81d04ecc20de57fe5. Eric, could that be your change?

The graph points to
Chromium Commit Position range: 540170 - 540595

My change simply added a layout test.

I suggest running another bisect, perhaps with a slightly different range.

Is the layout test I added run as part of xr.browsing.static?

I ran another test on 4dacae9837240e8c9f74f7db10662cb8eab5bba3 which is newer than when the regression happened. Got an even better result.

bsheedy@, my bisect script call is

chrome/test/vr/auto_bisect.py \
  --good-revision <good rev> \
  --bad-revision <bad rev> \
  --good-value 164481000 \
  --bad-value 172468000 \
  --metric memory:chrome:all_processes:reported_by_os:system_memory:proportional_resident_size_avg \
  '--story=index' \
  --swarming-server https://omnibot-swarming-server.appspot.com \
  --isolate-server omnibot-isolate-server.appspot.com \
  --build-target vr_perf_tests \
  --dimension pool,Hoverboard \
  --dimension id,vr-motopho-marlin \
  xr.browsing.static \
  --browser=android-chromium \
  --shared-prefs-file=chrome/android/shared_preference_files/test/vr_ddview_skipdon_setupcomplete.json

Is that wrong maybe?

VR browser perf tests need:
--profile-dir=gen/tools/perf/contrib/vr_benchmarks/vr_assets_profile
in order to use the browsing assets, which do have an impact on memory usage.

Oh, right. Trying that. Thanks!

Ok, with the assets all commits are bad. Also, this is the range where assets were first used for perf testing. That's probably the reason. Marking as won't fix.