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

Issue 632665 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jul 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

12.3% regression in blink_perf.shadow_dom at 408114:408153

Project Member Reported by alexclarke@chromium.org, Jul 29 2016

Issue description

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

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


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

android-nexus7v2
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Jul 29 2016

Cc: davidben@chromium.org
Owner: davidben@chromium.org

=== Auto-CCing suspected CL author davidben@chromium.org ===

Hi davidben@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Stop calling SSL_get_session in SSLClientSocketImpl.
Author  : davidben
Commit description:
  
In TLS 1.3, sessions are post-handshake, so they must only come in the
callback. This change is a no-op in TLS 1.2.

Also update the key_exchange_info to use the new SSL-based APIs. Otherwise
calling GetSSLInfo during a renegotiation may have problems. The SSL-based
APIs internally also have the same problem, but we can fix that while we
can't change SSL_get_session's behavior.

BUG= 630149 

Review-Url: https://codereview.chromium.org/2189613003
Cr-Commit-Position: refs/heads/master@{#408125}
Commit  : c269cc4baed868b167ad45838b4cc1ea6492b866
Date    : Wed Jul 27 14:56:50 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N   Good?
chromium@408113  1821.61  67.6282  18  good
chromium@408123  1853.56  19.369   5   good
chromium@408124  1844.9   49.3643  5   good
chromium@408125  1680.63  16.5173  5   bad    <--
chromium@408126  1753.05  54.7551  5   bad
chromium@408128  1717.58  32.815   5   bad
chromium@408133  1737.95  24.8993  5   bad
chromium@408153  1766.59  51.8626  18  bad

Bisect job ran on: android_nexus7_perf_bisect
Bug ID: 632665

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.shadow_dom
Test Metric: shadow-style-share-with-distribution/shadow-style-share-with-distribution
Relative Change: 0.29%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_perf_bisect/builds/3116
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9005812276125558560


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5245179028570112

| 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 Tests>AutoBisect.  Thank you!
Owner: alexclarke@chromium.org
This is completely implausible. I don't think Blink perf tests even run the SSL code. Re-run the bisect perhaps?
Status: WontFix (was: Assigned)
The ref build shows the same jump as ToT. Closing. Sorry for the noise!
I don't think this is a real regression, the ref moved too.

Sign in to add a comment