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

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


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

chromium-rel-mac-retina
chromium-rel-mac11-pro

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

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

Roll src/third_party/catapult/ 75149e9ea..ed32dd50b (2 commits)
By catapult-deps-roller@chromium.org · Wed Dec 20 18:07:03 2017
chromium @ 003ab0a14cdf6f54108faccc520e836df4d2ce55

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

perezju: Sorry for the late notice, bug was assigned to catapult-deps-roller. The CLs in the roll blamed for this regression are:

2017-12-20 perezju [Telemetry] Use --deny-permission-prompts
2017-12-20 perezju [Telemetry] Remove platform_backend.GetPortPairForForwarding

Any idea why either of these might regress cpu time metrics?

+dtu, has the roll into catapult since been fixed?

Hey, sorry, the bug isn't with performing the DEPS roll. Pinpoint just treats the last commit in the roll as the same commit as the roll itself. If you see it blame the roll, it means the last commit in the roll. Juan filed a bug today.
https://github.com/catapult-project/catapult/issues/4192

That means the regression was caused by:

[Telemetry] Use --deny-permission-prompts
https://chromium-review.googlesource.com/c/catapult/+/836553

+timloh any idea why adding this flag may have caused a cpu regression on mac?

(coincidentally, this appears to have fixed their corresponding ref builds?)

Also note, the regression happened with this story:
https://cs.chromium.org/chromium/src/tools/perf/page_sets/system_health/loading_stories.py?rcl=962060a19a82c53e585967f10dc3cf817e259943&l=338

I'd guess that the site is requesting location (or notifications?), and prior to using the flag we would've just left the prompt pending, and denying the prompt makes the site run some extra code.

Thanks for the explanation!

I'm leaning to close this as WAI, but I'm not very familiar with cpu_time_percentage to know whether the magnitude of the regression is acceptable or not.

Annie, +Charlie, do you know who owns that metric and could make a call?

I'm pretty sure dproy@ owns the CPU time metric. I know he owns the new one.

(If not, I'm probably the next obvious owner, but I haven't done any previous work on it, so that's terrifying.)

+deproy can you have look?

This is not a real regression. There are two things happening here: 

1. CpuTimePercentage reports cpu time as a percentage of the whole trace bounds. Before the regression, the 'StopAgentTracing' telemetry phase used to take ~16 seconds, and after the regression, it takes ~3 seconds. This makes the two traces very different lengths, and thus cpuPercentage looks drastically different. If we look at the total cpuTime (see cpuTime:all_processes:all_threads:all_stages:all_initiators in newCpuTime metric) the delta is not as drastic (on average 5600ms vs 6300ms) 

2. We still have to answer the question of why there is a ~700ms increase in absolute cpu time. It turns out the page has a periodic animation that steadily burns cpu. Before the regression, this animation started around 19s and continued until 22s when we closed the tab. After the regression, the animation started much earlier (perhaps disabling the notification prompt sped things up?) at around 15s, but still continued up to 22s. If I measure the cpu time consumed by the renderer process between 15s and 19s (using the range tool), it's roughly 700ms. 

Long story short, this is not a regression. Disabling the notification actually changed the page behavior (by starting the animation earlier.) And we should also switch to alerting on the total cpu time as opposed to cpu percentage (available in newCpuTimeMetric.) 

WontFix-ing per #12.

Deep, can you use the "Report Issue" -> "Request Monitoring for Tests" menu on chromeperf.appspot.com to request a monitoring update?