All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=871251

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=978233ae1e1adbc0f798024b2af3d7b97721486000787909bddce0aa073e8a3e


Bot(s) for this bug's original alert(s):

mac-10_12_laptop_low_end-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15d76558640000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/15d76558640000

Force OOPIF intersection observations after viewport update by kenrb@chromium.org
https://chromium.googlesource.com/chromium/src/+/eb3c53e64b63a74417d11b566c24081e5f386eb9
0.8447 → 0.9095 (+0.06477)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

My CL fixed a problem where we were potentially not rendering content that does need to be rendered. If that caused a performance regression that it is not too surprising, and it is also unavoidable. Should this just be closed?

+brucedawson, the benchmark owner.

Thanks for taking a look and for the explanation! It seems that your CL only affected low-end Macs:

https://chromeperf.appspot.com/report?sid=6195ff7fec23eb46557106275946a3dcbddd4671b8539dc211914979eb2306ab&start_rev=577083&end_rev=581003

Is that expected? Also, it's pushing the CPU usage up to > 95%. Isn't that too much?

The CL probably affected high-end macs as well but is just harder to see. The benchmarks are noisy enough that even on the low-end macs it is a bit hard to see.

It looks like the thing that makes the regression more obvious on the low-end Macs is that it is bumping up against the 1.0/100% ceiling. My concern there would be that if this test is mostly single threaded then when we hit 100% CPU we can't go any higher so we can't actually tell how much we have regressed. And, further regressions may be undetectable on low-end Macs because we are already at 100%. Do we have performance measurements as well that would detect if our frame rate or other performance metrics drop? Because once we have maxed out the CPU that is the only way that the benchmark can respond. That would mean that we could only see future regressions on the high-end benchmark.

That said, I don't know much/anything about the uol benchmark.

This is assigned to me but I don't know what to do with it. I don't know how to explain what is happening with the benchmark.

Ken: Since the graph is recovered to some extent (shows CPU usage at 89% now) and given the explanation in c#4 that the CL is a correctness fix, I think you can ignore this bug.

However, I agree with Bruce's concern about not being able to detect further regressions when we get close to 100%. Looking at the frame_times metric on low-end mac on a different benchmark and story (rendering.desktop/accu_weather_2018), I don't see any regressions:

https://chromeperf.appspot.com/report?sid=96ec852f47743216397e4bcdc29a847917f38181be18f1014a3a75f44326d5f5&start_rev=578061&end_rev=580493

I'll keep the bug open for more investigation by the GPU metrics team to see why rendering more content did not move any of the graphics metrics.