New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression

Blocking:
issue 832286



Sign in to add a comment

8.9%-362.8% regression in thread_times.tough_scrolling_cases at 548411:548615

Project Member Reported by primiano@chromium.org, Apr 9 Back to list

Issue description

See the link to graphs below.
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=830663

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


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

chromium-rel-win7-gpu-intel
chromium-rel-win7-gpu-nvidia
chromium-rel-win7-x64-dual
chromium-rel-win8-dual
📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/13a92824c40000
Cc: sullivan@chromium.org
Trying bisects on a few more platforms/pages.
Also trying a bisect without story filter.
📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/12bbafdcc40000
📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/14cd64acc40000
📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/148b84acc40000
Cc: pmonette@chromium.org engedy@chromium.org rkaplow@chromium.org agl@chromium.org
Owner: pmonette@chromium.org
Status: Assigned
📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/14a6d702c40000

webauthn: add test for oversized credential IDs. by agl@chromium.org
https://chromium.googlesource.com/chromium/src/+/ce1605967091027c08692ee570366d8b808a72fb

Adding fieldtrial config for the IncompatibleApplicationsWarning feature by pmonette@chromium.org
https://chromium.googlesource.com/chromium/src/+/7a86e22e588d7941bde54bdb4a8c58c23e502836

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions
Cc: -engedy@chromium.org -agl@chromium.org bokan@chromium.org nzolghadr@chromium.org
-agl, engedy: this is definitely not the webauthn CL above.

pmonette: There is a really clear jump in the benchmark at your CL in the bisect above. The regressions are pretty widespread (88 jumps on various pages and devices). Can you take a look? The pinpoint job above produced traces before and after your CL:

before: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/text_hover_50000_pixels_per_second_2018-04-11_16-30-02_98246.html
after: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/text_hover_50000_pixels_per_second_2018-04-11_19-20-58_36223.html

+benchmark owners bokan and nzolghadr in case they have thoughts here.
Blocking: 832286
Thanks for adding the benchmark owners!

I have a few questions about the benchmark.
Is my intuition correct that this is most probably caused by tasks running on the UI thread? Background tasks should not influence the scrolling?
Is this test done during startup or after?
> Is my intuition correct that this is most probably caused by tasks running on the UI thread? Background tasks should not influence the scrolling?

Yes, the scroll itself occurs in the renderer process.

> Is this test done during startup or after?

After, we wait until the page is loaded then begin scrolling.

Despite owning it (the scrolling side, anyway) I don't have a deep understanding of this benchmark. That said, I believe thread_times is measuring amount of CPU time spent in each generated frame in various threads over the scroll. It looks like this regressed thread_times_all, which is a combination of some bucket of threads but I'm not sure which. In that case, doing a significant amount of work on any thread this is measuring would cause this to regress. 

One thing to note, the traces sullivan@ attached don't have much detail. You can get a much clearer picture by running the benchmark locally, with and without your patch, while capturing a trace (I think this benchmark automatically captures a trace). Use --extra-chrome-categories="*" in run_benchmarks to specify all the detail in the trace, there'll be a link to it on the results page.
 Issue 830788  has been merged into this issue.
 Issue 830656  has been merged into this issue.

Sign in to add a comment