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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgpoCgnAsM


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

chromium-rel-win7-x64-dual

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8977854191015745808

=== Auto-CCing suspected CL author dcheng@chromium.org ===

Hi dcheng@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Daniel Cheng
  Commit : 6a32dcf0c4968f022b2f603912ce2804606636e1
  Date   : Wed May 31 21:32:10 2017
  Subject: Use task cancellation status in base::MessageLoop.

Bisect Details
  Configuration: win_x64_perf_bisect
  Benchmark    : smoothness.gpu_rasterization.tough_path_rendering_cases
  Metric       : frame_times/GUIMark Vector Chart Test
  Change       : 5.68% | 17.9000521956 -> 18.9167841528

Revision             Result                   N
chromium@475984      17.9001 +- 0.441302      6      good
chromium@476026      18.0306 +- 0.270915      6      good
chromium@476032      17.9847 +- 0.236388      6      good
chromium@476033      18.8863 +- 0.370788      6      bad       <--
chromium@476034      19.0659 +- 0.250742      6      bad
chromium@476035      18.8125 +- 0.347084      6      bad
chromium@476037      18.9528 +- 0.458266      6      bad
chromium@476047      18.9151 +- 0.271072      6      bad
chromium@476067      18.8746 +- 0.434419      6      bad
chromium@476150      18.9168 +- 0.400741      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=GUIMark.Vector.Chart.Test smoothness.gpu_rasterization.tough_path_rendering_cases

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8977854191015745808

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6206355129499648


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

Explictly assigning. A CL you landed tripped one of the speed metrics we measure in the lab. If this is the first time this has happened to one of your CLs, or if it's been a while, please read: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/addressing_performance_regressions.md

We're looking for one of the following:
1. Justification via explanation
2. Plan to revert or fix
3. Angry rage throwing of equipment at my head

Just be aware that I'm trained in trumpet playing and First Aid and am not afraid to use it.

Note: This was a bulk edit message and not very personal.

dcheng: any progress here?

+senorblanco, test owner: since this bug is pretty old, is it still worth investigating?

Since it's only 5%, we can probably live with the regression, but it would be nice if the patch author could take a look to see if there's something obvious.

Sorry I don't really have any good ideas of how to investigate here. In theory, the patch in question should cause us to spin less (before, dispatching a cancelled task still counted as doing work, whereas now we pop tasks until we find a non-cancelled task or the queue is emptied). It's hard for me to hypothesize how this could have triggered this regression, unless there's some sort of CPU thrashing that now happens?

I'm happy to try to take some before and after profiles, but it's a pretty big mystery to me how these tests work: what are they measuring, how do I hook into to run pprof, et cetera.

senorblanco, can you help out with #8?

The Vector Chart test is a snapshot of http://www.craftymind.com/factory/guimark2/HTML5ChartingTest.html. It's a 2D <canvas> test. The two bots that it is regression on here have no GPUs, so they're sure to be doing CPU rendering (software compositor, raster skia backend). You can simulate this locally with --disable-gpu.

If I remember correctly, when canvas is run on the CPU, it uses a single-threaded rendering . But Justin would know for sure. At any rate, it should be possible to profile it like so: https://chromium.googlesource.com/chromium/src/+/master/docs/linux_profiling.md. Profiling the renderer thread is somewhat tricky, but you can often simulate what would happen with --single-process.

dcheng, did you take a look per #10?

I talked with gab about this today and one theory is that the renderer main loop is less responsive due to the cancelled task sweeping.

Looks like the graphs for this regression are gone now (no data). dcheng: Is this a WontFix?

The NextAction date has arrived: 2018-10-31