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

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


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

android-nexus6

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

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

This test hasn't been running for very long, and appears to give very noisy measurements.

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

Add NavigationMojoResponse to field trial config. by arthursonzogni@chromium.org
https://chromium.googlesource.com/chromium/src/+/e8d15ffeac9c1ca0005dd649c27c20533e4ff44e

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

One question: Is the experiment always used in this benchmark after using the field trial config?
If it is always used, maybe I can use pinpoint to see if reverting this CL causes a difference. Let me know.

On the graph, I am not seeing a difference with the two commits before mine. Is it possible the regression was introduced before my CL?

There is a finch config for NavigationMojoResponse here:
https://uma.googleplex.com/p/chrome/variations/?sid=876e62a7b4f217f6db942683f088c7f9
Maybe there is an histogram corresponding to this benchmark.

The goal of NavigationMojoResponse is to avoid the renderer making an additional request (and one IPC round trip with the browser) to get the main resource response. The document starts loading earlier, but maybe it's less time for the other tasks in the renderer process to execute.

I tried running the same benchmark + story with the revert of my patch.
https://chromium-review.googlesource.com/c/chromium/src/+/983596

Unfortunately, when I press [start] on pinpoint, nothing happens :-(
I will try again latter. 

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/13bdc3c7440000

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

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

Add NavigationMojoResponse to field trial config. by arthursonzogni@chromium.org
https://chromium.googlesource.com/chromium/src/+/e8d15ffeac9c1ca0005dd649c27c20533e4ff44e

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

In both the pinpoint bisect jobs, my patch is found to be the cause of the regression, but in both case, the result on the graph doesn't seem to be different with and without my patch. Also, there is no line connecting the point of my patch with the one before. @isherman, what does it means?
Do you think is it possible my patch is found in the bisection only because the field trial config has changed?

I tried to run again the same benchmark test with and without my patch:
https://pinpoint-dot-chromeperf.appspot.com/job/13bdc3c7440000
and no difference was found.

+simonhatch for the question about pinpoint

FYI: It looks like the graph came back to its previous values (See graph).

Deleted: perf.png 130 KB

	perf.png 130 KB View Download

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

Graph kinda looks bi-modal, and after the regression just stays at the high value more often. The values from the waterfall and the values from pinpoint don't really match though, Pinpoint only seems to be chasing a really small regression vs what the waterfall saw. I'll try expanding the range and running it again.

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

Add NavigationMojoResponse to field trial config. by arthursonzogni@chromium.org
https://chromium.googlesource.com/chromium/src/+/e8d15ffeac9c1ca0005dd649c27c20533e4ff44e

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

Bisection seems to always ends on my patch.
simonhatch@, do you know what means the segments that connects the points on the graph? And why there are no segment between my patch and the previous one?
I know how to run a benchmark with/without a patch, how can I run a benchmark on a range of CLs?

Given that the benchmark values came back to the previous normal and every other CLs around mine (+/- 6) shows similar results (+/- 0.04%), I am unassigning myself from this bug and stay in CC. Feel free to re-assign me if you think there is something with my CL. 

Deleted: fH7XK7PhPOC.png 37.4 KB

	fH7XK7PhPOC.png 37.4 KB View Download

+dtu

Hmm same result, still seems to converge on your cl. The disconnects between segments represent where Pinpoint thinks there's a difference.

We're not really getting what the waterfall saw either, too bad there's no ref build to check. Dave, any ideas?

dtu: ping on #18?

Ping: dtu@

Hi, sorry, this fell off my radar.

The Pinpoint graphs show the medians. I pulled the means out of the data, and got these numbers:
r543197: 17.3811
r543356: 17.3944
r543395: 17.2625
r543415: 17.3084
r543425: 17.3281
r543427: 17.3082
r543428: 17.8077
r543430: 17.8538
r543435: 17.8642
r543515: 17.9069
r543834: 17.8562

Although the medians don't show a big change, the means show a change of roughly +0.5 or +0.6 ms, which is closer to what we saw on the waterfall.

Thanks dtu@!
So the mean increased, but the median stays the same.

NavigationMojoResponse only deals with providing the renderer process the data pipe for reading the main resource response. Then the document loads and becomes interactive. NavigationMojoResponse's job ends just before the document start loading data, so that's a bit weird it can regress performance of scrolling.

I have one hypothesis. Before NavigationMojoResponse (See design doc: https://goo.gl/Rrrc7n), the renderer needed to do 2 requests to the browser process to get the main resource response. Now, only one request is made. There is less latency, loading can start slightly earlier.

[Windows] https://uma.googleplex.com/p/chrome/variations/?sid=f1b53b056505c6848e7e08fc92fc2be4
[Android] https://uma.googleplex.com/p/chrome/variations/?sid=c0d4b7a50c0534b60f0c42342399cc8f

Before NavigationMojoResponse, the renderer process had a few more milliseconds to execute some tasks and get less busy before loading a new document. Maybe the renderer process is now more busy when the document becomes interactive. It could produce some outlier data point and increases the mean without touching the median.

---

The benchmark numbers came back to the normal, it would be nice to understand why. Maybe pinpoint could bisect which CL after mine did this.
NavigationMojoResponse landed. The old code path has been removed and a lot of complexity have been removed:
https://chromium-review.googlesource.com/c/chromium/src/+/1015005
Several other projects depended directly on NavigationMojoResponse. So it doesn't look possible to go back.
I don't know what I can do immediately.

Given prior comments, it seems this issue is a WontFix.

arthursonzogni: Please re-open if there is more to be done on this issue.