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

Issue 868044 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

10.3% regression in blink_perf.bindings at 577424:577437

Project Member Reported by ushesh@chromium.org, Jul 26

Issue description

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

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


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

mac-10_12_laptop_low_end-perf
Cc: herhut@chromium.org
Owner: herhut@chromium.org
Status: Assigned (was: Untriaged)
📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/13eb0b3ba40000

[cleanup] Move handle() function to handles-inl.h by herhut@chromium.org
https://chromium.googlesource.com/v8/v8/+/7ead0c146e16661951583d18fda64a73492910c0
2930 → 3256 (+326.8)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions
This only regresses on macos. I will have to investigate on a mac. Maybe it is a specific compiler version that triggers different inlining.

I ran the benchmark with 

tools/perf/run_benchmark blink_perf.bindings --browser=exact --browser-executable=out/Release/chrome   --story-filter=gc-tree --show-stdout


Sign in to add a comment