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

Issue 700853 link

Starred by 2 users

Issue metadata

Status: WontFix
Merged: issue 700364
Owner:
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug-Regression

Blocking:
issue 698746


Show other hotlists

Hotlists containing this issue:
I-TF-Launch


Sign in to add a comment

11.9% regression in blink_perf.shadow_dom at 455720:455816

Project Member Reported by hjd@chromium.org, Mar 13 2017

Issue description

See the link to graphs below.
 

Comment 1 by hjd@chromium.org, Mar 13 2017

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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtMaKswoM


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

chromium-rel-mac-retina
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Mar 13 2017

Mergedinto: 700364
Status: Duplicate (was: Untriaged)

=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Michael Hablich
  Commit : 7c3936c67a6361371d9a00d83e2c03ecc603ce76
  Date   : Thu Mar 09 08:05:42 2017
  Subject: Version 5.9.34.1 (Turn on I+TF)

Bisect Details
  Configuration: mac_retina_perf_bisect
  Benchmark    : blink_perf.shadow_dom
  Metric       : v1-slot-append/v1-slot-append
  Change       : 10.28% | 5231.29406211 -> 4693.47516699

Revision                           Result                  N
chromium@455719                    5231.29 +- 204.086      6      good
chromium@455719,v8@7c3936c67a      4484.07 +- 189.209      6      bad       <--
chromium@455719,v8@fbffc377e3      4545.83 +- 115.663      6      bad
chromium@455720                    4456.63 +- 268.699      6      bad
chromium@455721                    4526.42 +- 109.152      6      bad
chromium@455723                    4502.58 +- 199.341      6      bad
chromium@455726                    4519.57 +- 137.854      6      bad
chromium@455732                    4554.08 +- 179.615      6      bad
chromium@455744                    4481.26 +- 192.014      6      bad
chromium@455768                    4493.4 +- 161.221       6      bad
chromium@455816                    4693.48 +- 253.091      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.shadow_dom

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8985238962234364864

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6464502490464256


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

Comment 4 by hjd@chromium.org, Mar 13 2017

Blocking: 698746
Status: Untriaged (was: Duplicate)
Cc: jochen@chromium.org verwa...@chromium.org
Click the link for "Original alerts at time of bug-filing:" to get the original alert. Seems like "v1-slot-append" regresses over all platforms.

Is this the same regression that makes Polymer 2.0 slightly slower?
Components: Blink>JavaScript
Status: Available (was: Untriaged)

Comment 8 by jochen@chromium.org, Mar 14 2017

Cc: bmeu...@chromium.org
Cc: rmcilroy@chromium.org
SmallDistributionWithLayout also got a higher variance around that time. The ref build is still ok, so I suspect that it is not a bot problem.
Owner: mvstan...@chromium.org
Status: Assigned (was: Available)
mvstanton@ is going to further triage this.
With --turbo on there is a function that gets optimized twice by TurboFan, once normally, and then again with TurboFan OSR:

[compiling method 0x1ddf214db5b1 <JSFunction GCController.collectAll (sfi = 0x1ddf214dac69)> using TurboFan]
[optimizing 0x1ddf214db5b1 <JSFunction GCController.collectAll (sfi = 0x1ddf214dac69)> - took 0.161, 0.627, 0.065 ms]
[completed optimizing 0x1ddf214db5b1 <JSFunction GCController.collectAll (sfi = 0x1ddf214dac69)>]
[compiling method 0x1ddf214db5b1 <JSFunction GCController.collectAll (sfi = 0x1ddf214dac69)> using TurboFan OSR]
[optimizing 0x1ddf214db5b1 <JSFunction GCController.collectAll (sfi = 0x1ddf214dac69)> - took 0.134, 0.448, 0.044 ms]

Aside from that, nothing about the run looks different. There are no deoptimizations taking place in either pipeline configuration.

So I don't see anything unusual to explain the degrade yet...
Running with profiler ticks, in the Crankshaft case we spend more time in optimized code (70 ticks in method run(), verses 44 with --turbo). Otherwise everything is the same. Only 1-2% of time is in JavaScript for this test, the majority of the time is spent in GC and api calls (~4600 ticks in Builtin_HandleApiCall).

I'd attribute this result to our known issue that we are running more in the interpreter than in optimized code across several scenarios (a google maps rendering test we are looking at, typescript). In a small way, the same thing is showing up here.


WITHOUT IGNITION+TURBOFAN
 [Summary]:
   ticks  total  nonlib   name
    149    1.7%    1.7%  JavaScript
   8711   97.7%   97.9%  C++
   1029   11.5%   11.6%  GC
     20    0.2%          Shared libraries
     34    0.4%          Unaccounted

WITH
 [Summary]:
   ticks  total  nonlib   name
    103    1.1%    1.1%  JavaScript
   8837   98.3%   98.5%  C++
    986   11.0%   11.0%  GC
     18    0.2%          Shared libraries
     33    0.4%          Unaccounted

Blocking: -698746
Blocking: 698746
Labels: -Pri-2 Pri-3
Blocking to show the relationship but de-priotizing. This is not important for the M59 stable launch.
No movement in about 6 months, should we WontFix?
Status: WontFix (was: Assigned)
WontFix-ing after no update from #15, please reopen if you're still planning on fixing this.

Sign in to add a comment