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

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


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

chromium-rel-mac-retina
chromium-rel-mac11
chromium-rel-mac11-air
chromium-rel-mac11-pro
chromium-rel-win7-dual
chromium-rel-win7-gpu-nvidia
chromium-rel-win7-x64-dual
chromium-rel-win8-dual
win-high-dpi

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12cd9cf4040000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/12cd9cf4040000

recovered (and may not be a real regression)

pmeenan: can you check the reasoning in  issue 792061 ? I think there is a regression here that was only fixed because I landed an optimization for another regression.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14e06a44840000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11ef7444840000

thanks, mlippautz. re-kicking bisects.

📍 Found significant differences after each of 5 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/11ef7444840000

Simplified PrefServiceFactory's setters.
By fdegros@chromium.org · Mon Dec 04 00:14:44 2017
chromium @ a239602a8b9898620d2893045f0ddbabf4ed9942

Remove calls to styleForLayoutObject() in LayoutTreeBuilder::style()
By nainar@chromium.org · Mon Dec 04 01:01:29 2017
chromium @ b71f5b7df345f1a8603b7cf7b59edf48288e7d96

[LayoutNG] Handle margins at unforced breaks.
By mstensho@chromium.org · Mon Dec 04 01:04:41 2017
chromium @ 69ce9102d1e6aaa81a3344716a73c5aec9e8bbc5

Make mouse events aware of root layer scrolls
By bokan@chromium.org · Mon Dec 04 01:12:25 2017
chromium @ 4ca1c620a075f74d526126a0cb411217b0ba417a

Implment ThrottlingPolicy on ResourceLoadScheduler
By yhirano@chromium.org · Mon Dec 04 01:32:09 2017
chromium @ da009d152fa1785bb706c1a73af09a48197a34d5

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

📍 Found significant differences after each of 3 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/14e06a44840000

Simplified PrefServiceFactory's setters.
By fdegros@chromium.org · Mon Dec 04 00:14:44 2017
chromium @ a239602a8b9898620d2893045f0ddbabf4ed9942

Remove calls to styleForLayoutObject() in LayoutTreeBuilder::style()
By nainar@chromium.org · Mon Dec 04 01:01:29 2017
chromium @ b71f5b7df345f1a8603b7cf7b59edf48288e7d96

Implment ThrottlingPolicy on ResourceLoadScheduler
By yhirano@chromium.org · Mon Dec 04 01:32:09 2017
chromium @ da009d152fa1785bb706c1a73af09a48197a34d5

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

It looks lower is better, and according to https://pinpoint-dot-chromeperf.appspot.com/job/11ef7444840000 the value got down after my change.

yhirano: thanks, you're right, the bisect in #10 shows an improvement at your CL, and both bisects show clear improvements at nainar's CL.

Assigning to jbroman, owner of the blink_perf.dom benchmark. Both the bisects and the graphs show a lot of up-and-down movement. We do see a small regression in each bisect at fdegros's change, "Simplified PrefServiceFactory's setters.". But since there is so much movement in the benchmark, and PrefServiceFactory doesn't seem like it should affect a test called "move-down-with-hidden-elements", I wanted to check that you feel this is a real regression before assigning to fdegros to look. Maybe this test is too sensitive?

+editing people

There are multiple editing changes that touch selection code (which is what this tests) in the regression ranges I see in chromeperf, so this might be real. PTAL.

(I'm not sure I'm quite willing to believe what pinpoint says, but the graph definitely seems to point at something happening here.)

>#c13, I could not find selection related code in the range[1].
Could you provide the list of commits mentioned in #c13? 



[1] https://chromium.googlesource.com/chromium/src/+log/b71f5b7df345f1a8603b7cf7b59edf48288e7d96%5E..73505ae3cd98481051c5285993713676467ac31d?pretty=fuller&n=1000

via https://chromeperf.appspot.com/report?sid=9058a571d0530d9b33d8f7ce3ec8f8f202e8be0a1ff1b04713080a4321c8a19d&rev=521272, there seem to be two regressions (one of which has recovered), with ranges:

https://chromium.googlesource.com/chromium/src/+log/9babae35239597ad2b18fb5c4f00d2e44b47c649..c365e1fb592eb3e9d9b1dcc06dafad8de41f98f8
https://chromium.googlesource.com/chromium/src/+log/3a13f63d2ad6f26c9aefdd2d2a7f8fa34571f23e..73505ae3cd98481051c5285993713676467ac31d

the former, at least, has selection-related CLs (though looking again, that step may be  bug 792061 ). Still, both steps up look real in the graph (ref is unaffected), and the test in question is a selection microbenchmark.

>#c16, Thanks for providing range.

From first range: https://chromium.googlesource.com/chromium/src/+log/9babae35239597ad2b18fb5c4f00d2e44b47c649..c365e1fb592eb3e9d9b1dcc06dafad8de41f98f8
- 795493 Compute selection bounds straightforward
- 791856 Fix HTMLOutputElement::CanContainRangeEndPoint
- 795363 Simplify argument list of ComputeInlineBoxPosition
- 786397 Simplify TextControlElement::ComputeSelectionStart/End

From second range: https://chromium.googlesource.com/chromium/src/+log/3a13f63d2ad6f26c9aefdd2d2a7f8fa34571f23e..73505ae3cd98481051c5285993713676467ac31d
- 765097 Remove calls to styleForLayoutObject() in LayoutTreeBuilder::style()
Node::GetLayoutObject()->Style() to Node::GetComputedStyle()
This is already recovered.

Bisecting... https://pinpoint-dot-chromeperf.appspot.com/job/14a7b5ec840000

Mark Fixed

First range mentioned in #c18 is already fixed as  issue 792061 .
Second range mentioned in #c18 is recovered.

The performance test measures computation of visible selection.
The first range regression was caused by Oilpan write barrier.
The second part regression seems to be computed style related.