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

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


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

linux-perf
mac-10_12_laptop_low_end-perf
mac-10_13_laptop_high_end-perf

system_health.memory_desktop - Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

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

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/14a6a4ec540000

All of the runs failed. The most common error (20/20 runs) was:
ReadValueError: Could not find values matching: {'story': u'load:search:taobao', 'tir_label': u'load_search', 'histogram': u'console:error:all'}

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

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

Reland [Optimize TaskQueueSelector] by alexclarke@chromium.org
https://chromium.googlesource.com/chromium/src/+/0c17bc4823f8506061a7f20935f95f0d71d4ad5c
console:error:all: 8.7 → 17.8 (+9.1)

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

Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

 Issue 922561  has been merged into this issue.

 Issue 922587  has been merged into this issue.

 Issue 922562  has been merged into this issue.

 Issue 922586  has been merged into this issue.

 Issue 922590  has been merged into this issue.

That patch changed the interleaving of some task queue prioritises.  This kind of regression is unexpected and suggests there's some blink code making bad assumptions. 

Or more of the page is loading before the test ends. I wrote a quick test to investigate the task interleaving differences.  The idea is it posts a task of each priority that appends the priority to a string.  This is repeated 60x and then all tasks are run.  This gives a feel for the ordering differences:

Before those where run in this order:

  "000000000000000000000000000000000000000000000000000000000000" 
  "111231112341112311123411123111234111231112341112311123411123"
  "111234111231112341112311123411123111234111231112342223242223"
  "242223242223242223242223242223242223242223242223243333343333"
  "343333343333343333343333344444444444444444444444444444444444"
  "555555555555555555555555555555555555555555555555555555555555"

After the tasks where run in this order:
  "000000000000000000000000000000000000000000000000000000000000"
  "111121111213112141121113121111211412311121111211312411121111"
  "231112114121131211112111123412222223222224223222222223242222"
  "223222222423222222223433333343333334333333433333343333334333"
  "333433333343333344444444444444444444444444444444444444444444"
  "555555555555555555555555555555555555555555555555555555555555"

The main difference is tasks are run slightly more in priority order now (i.e. high priority tasks will tend to run a bit sooner).

It seems hard to imagine how doing that could cause a real regression. 

+Sami WDYT?  

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a47007c8869af68a5657af2171763d32ab4d61a6

commit a47007c8869af68a5657af2171763d32ab4d61a6
Author: Alex Clarke <alexclarke@chromium.org>
Date: Thu Jan 17 17:32:40 2019

Add a test to help visualize task priority interleaving

Bug: 922538
Change-Id: I196c81119c6a8c313fb0125913e72a023caa2086
Reviewed-on: https://chromium-review.googlesource.com/c/1418150
Auto-Submit: Alex Clarke <alexclarke@chromium.org>
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623737}
[modify] https://crrev.com/a47007c8869af68a5657af2171763d32ab4d61a6/base/task/sequence_manager/sequence_manager_impl_unittest.cc

 Issue 923039  has been merged into this issue.