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

Issue 886889 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 20
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

11.3% regression in rasterize_and_record_micro.top_25 at 591974:591997

Project Member Reported by alexclarke@chromium.org, Sep 19

Issue description

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

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


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

Android Nexus5X WebView Perf

rasterize_and_record_micro.top_25 - Benchmark documentation link:
  None
Cc: afdo-chr...@skia-buildbots.google.com.iam.gserviceaccount.com
Owner: g...@chromium.org
Status: Assigned (was: Untriaged)
📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/123ef23f640000

Roll AFDO from 71.0.3554.0_rc-r1 to 71.0.3555.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/4b8803051fc24556622b6c8532a7b7ba73f64a8d
4.507 → 4.986 (+0.4791)

Assigning to sheriff gbiv@chromium.org because "Roll AFDO from 71.0.3554.0_rc-r1 to 71.0.3555.0_rc-r1" is a roll.

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

Benchmark documentation link:
  None
Looks like the third obvious instance of AFDO-induced noise in the last month (the first being r590096 -> r590245, and the second being r590623 -> r590934). Which is slightly concerning, but not the end of the world.

We're still on the 3555 profile, so I'll give it time to see if a later roll fixes this (as happened with the previous two alerts). If I get many more complaints about this particular story of this particular benchmark, I can investigate + try to see if I can do a spot fix.

For context, AFDO profiles are generated by sampling Chrome's execution and feeding that back into the compiler, so the compiler can better optimize Chrome. This process is inherently noisy, so we'll sometimes see benchmarks that are highly sensitive to certain optimizations being performed (read: many of blink's benchmarks) swing around from time to time, and we’ll sometimes see Chrome vary in size as the inliner decides to be more/less aggressive. Denoising this in general is being tracked in issue 849881.
Status: Fixed (was: Assigned)
(Incoming copy-paste ;) )

At this point, I've received five perf bugs for this single 3555 profile roll, all of which have recovered with the 3556 roll.

It's rare (< monthly), but we will occasionally have a profile that's just way off. I'll look into whether there's any obvious reason for this particular flake (we use Chrome ToT; if that crashes or glitches out a benchmark, or profile gets really skewed), but given that everything's back to normal and there's ~no signal we can realistically get from these flakes, ...

Hopefully our swap to field-focused profiles (Q4 maybe?) will make this issue go away, but only time will tell.

Added a note of this all in the denoising bug, issue 849881.

Sign in to add a comment