New issue
Advanced search Search tips

Issue 828283 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

3.1%-4.7% regression in speedometer at 539397:543461

Project Member Reported by bmeurer@google.com, Apr 3 2018

Issue description

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

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


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

android-nexus7v2
chromium-rel-win10
chromium-rel-win7-gpu-ati
Cc: cbruni@chromium.org gsat...@chromium.org
Owner: cbruni@chromium.org
Status: Assigned (was: Untriaged)
📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/12820be0c40000

[printing] Improve ScopeInfo printing by cbruni@chromium.org
https://chromium.googlesource.com/v8/v8/+/6d1ce93558579284c7a1a787f1c7be8669a85d68

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions
Status: WontFix (was: Assigned)
Looking at the graphs the bump is within the noise of the previous runs.

I'm not fully sure how my CL would be able to cause this regression.
I added printing for ScopeInfo to HeapObjectShortPrint and the following helper in globals.h:
inline std::ostream& operator<<(std::ostream& os, ScopeType type) {

Unless this massively changed inlining somewhere (which it shouldn't since all other users are debug-only).

Sign in to add a comment