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

Issue 786123 link

Starred by 0 users
Status: WontFix
Owner:
█ ajwong@chromium.org
Last visit > 30 days ago
Closed: Dec 2017
Cc:
m...@chromium.org
tdres...@chromium.org
erikc...@chromium.org
█ brettw@chromium.org
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

11.9%-12% regression in system_health.common_desktop at 516565:516656

Project Member Reported by m...@chromium.org, Nov 16 2017 
See the link to graphs below.
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Nov 16 2017 

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

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


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

linux-release
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Nov 16 2017

Cc: brettw@chromium.org ajwong@chromium.org
Owner: ajwong@chromium.org
Status: Assigned (was: Untriaged)
📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/15f1f655f80000

Enable frame pointers in linux.
By ajwong@chromium.org · Wed Nov 15 06:16:22 2017
chromium @ 9f966099a3d6f91c80016226fe9d33981f291689

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

Comment 4 by ajwong@chromium.org, Nov 20 2017

Cc: erikc...@chromium.org
Owner: tdres...@chromium.org
Looking at the breakdowns, the parseHTML time actually decreases but the layout time increases.  Chatting with erikchen, we're suspecting the regression might actually just be caused by a different amount of work getting done in the tests.

@tdresser: Does that analysis seem correct?
original-breakdown.png
178 KB View Download
regressed-breakdown.png
180 KB View Download

Comment 5 by tdres...@chromium.org, Nov 21 2017

Cc: -ajwong@chromium.org tdres...@chromium.org
Owner: ajwong@chromium.org
What's your hypothesis for why a different amount of work is getting done in the tests?

Comment 6 by ajwong@chromium.org, Nov 21 2017 

So the specific change introduced framepointers into most of the generated function call code.  If there were a significant systemic regression, I would have expected it across the board as opposed to just one or two stories.

What the change likely does though is shake up the task scheduling amongst all message loops. Parsing and Layout, AIUI, are async workflows inside blink meaning wallclock time can get perturbed.  If you look at the cpu time measured, you'll see that parseHTML in the "regressed" version actually runs faster than the original version. This is weird as you'd expect adding framepointers per call to slow things down.

So that seems to be contravariant to the regression in the amount of time layout takes. This makes me think we're laying out a different set of dom nodes.

Thoughts?

Comment 7 by ajwong@chromium.org, Dec 4 2017

Status: WontFix (was: Assigned)
Closing won't fix per reasoning in #6.
►

Sign in to add a comment