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

Issue 814049 link

Starred by 2 users
Status: WontFix
Owner:
gab@chromium.org
Closed: Feb 2018
Cc:
mlippautz@chromium.org
█ briander...@chromium.org
gab@chromium.org
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

3.7%-12.8% regression in thread_times.tough_compositor_cases at 536126:536241

Project Member Reported by briander...@chromium.org, Feb 21 2018 
See the link to graphs below.
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Feb 21 2018 

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

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


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

android-nexus5
android-nexus6
android-nexus7v2
android-one
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Feb 23 2018

Cc: gab@chromium.org mlippautz@chromium.org
Owner: gab@chromium.org
Status: Assigned (was: Untriaged)
📍 Found a significant difference after 1 commit.
https://chromeperf.appspot.com/job/11f4f327840000

Fix 'num cores' in ConcurrentMarking as well. by gab@chromium.org
https://chromium.googlesource.com/v8/v8/+/8996e262cc880d6d12ac7dc468964e6313fde023

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

Comment 4 by gab@chromium.org, Feb 26 2018

Status: WontFix (was: Assigned)
We do see those improved when r534414 landed (which caused a performance regression fixed by #3).

IIUC : tasks_per_frame_other/thread_other_cpu_time_per_frame metrics are effectively saying that we're using more CPU per frame. That's precisely the goal of concurrent marking.

If it didn't regress actual timings (e.g. compositor slower because too many workers), then this is WAI.
►

Sign in to add a comment