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

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


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

android-one

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

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

Add finch testing config for VizHitTestDrawQuad. by riajiang@chromium.org
https://chromium.googlesource.com/chromium/src/+/4ae8cd29d704de6767b1c323095f565b97acef39

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

thread_browser_cpu_time_per_frame/http___jsfiddle.net_ugkd4_10_show_ is the affected test. I didn't find the testing code, is it related to hit-testing time? What't the difference between thread_times.key_hit_test_cases and thread_times.key_silk_cases?

It looks like there was already some regression at 558300 - 558448 (4.40 to 4.44) from https://chromeperf.appspot.com/group_report?bug_id=844630 though.

Because this is cpu-time in browser, I suspect the hit-test is a bit involved: aggregation, targeting, and location-transforming would all contribute to this. I looked at the UMA, and the numbers we currently have are measured in ms, which makes it tricky to see if that explains this small bump. It would be a good idea to measure these numbers in microseconds instead.

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

commit 3ab1e84b8224ffc9d9ad295cf8dfac109e764edd
Author: Ria Jiang <riajiang@chromium.org>
Date: Tue Jul 10 18:08:36 2018

Add metrics to measure aggregate, target and transform in us.

Bug:  844630 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I404d10eb61aa24ae76adf4b5ea19794e95744928
Reviewed-on: https://chromium-review.googlesource.com/1127455
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Ria Jiang <riajiang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#573810}
[modify] https://crrev.com/3ab1e84b8224ffc9d9ad295cf8dfac109e764edd/components/viz/host/hit_test/hit_test_query.cc
[modify] https://crrev.com/3ab1e84b8224ffc9d9ad295cf8dfac109e764edd/components/viz/service/hit_test/hit_test_aggregator.cc
[modify] https://crrev.com/3ab1e84b8224ffc9d9ad295cf8dfac109e764edd/tools/metrics/histograms/histograms.xml

Let's revisit next week and look at the new numbers to see how much of the change can be attributed to viz hit-testing.

On windows dev, Event.VizHitTest.AggregateTimeUs is taking the most time - mean is 5 microseconds; both targeting and location transformation are pretty fast - targeting mean 1 microseconds, transform mean 0 microseconds.

https://uma.googleplex.com/p/chrome/histograms/?endDate=20180731&dayCount=7&histograms=Event.VizHitTest.AggregateTimeUs%2CEvent.VizHitTest.TargetTimeUs%2CEvent.VizHitTest.TransformTimeUs&fixupData=true&showMax=true&filters=platform%2Ceq%2CW%2Cchannel%2Ceq%2C2%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial 

How do we make sure if these numbers align with the 1.3% bump?

The regression was ~100us, so viz hit-test is not the main contributor here.

There was a much larger regression before this, and that has recovered. So I am going to wontfix this. Thanks for ruling out the viz hit-test stuff.