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

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


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

chromium-rel-mac11-pro
chromium-rel-win7-gpu-ati
linux-release

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

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

Use explicit API to request code cache.
By mythria@chromium.org · Mon Jan 22 17:23:23 2018
chromium @ 76067d1c63e1e6b2ba456059c78532a748f8f41a

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

I am not sure why there is a regression. That cl shouldn't have changed anything in the overall time. It should just request the code cache explicitly. Earlier it was requested along with compile requests. I will take a look. 

I looked into this. I still don't see why it regressed. It any what I noticed is a small improvement in the second run (if using the same renderer) since after my change we reuse the code in isolate cache. Earlier, we used to compile if we want to produce cache even if there is a hit in isolate. Again, this improvement is very slight (2-3 ms) and we run it for 10 iterations. So I don't really expect to see any difference.

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

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

I am looking at it again, the scripts that are cached are the same before and after my cl. I verified that we produce and consume cache for the same set of scripts and nothing has changed there. When looking at the traces for the individual runs I cannot see the regression. I kind of think my cl may not be the actual culprit. I will try to bisect it again to verify this.

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

I also notice that the graphs are recovering. I think it was some timing issue which got fixed. I will wait for the bisect results and wait a couple of more days to check the progress on the bots.

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

Fix rootScroller when iframe's view is swapped. by bokan@chromium.org
chromium @ 3f0b9946f52dc4e146e90e7377974e12a76404b5

Revert "Skip unnecessary invalidation of document level NodeList caches" by adithyas@chromium.org
chromium @ e4dc91a1eef20385d060e04760de3641989950e5

[oilpan] Extract visitor from marker by mlippautz@chromium.org
chromium @ bf779fc562b95cc6a65b3f5a045f2777f97232af

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

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

Triggered another bisect. None of the suspects in earlier bisect look quite strong.

It's believable to me that the revert of Adithya's CL (the original CL was intended to improve S2 performance) would regress it.

My CL was reverted (and still is). Will check if the graphs recovered once I get my hands on a workstation.

#14: +1, the revert of my CL definitely caused a regression, and IIRC there was another issue that was created for a speedometer regression that was caused by it. 

Thanks adithyas@ and jborman@. I wasn't sure because the original cl landed @527730 and I did not see any performance improvements there. So, I wasn't too sure.

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

Use explicit API to request code cache. by mythria@chromium.org
chromium @ 76067d1c63e1e6b2ba456059c78532a748f8f41a

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