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

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


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

chromium-rel-mac11

=== Auto-CCing suspected CL author sigbjornf@opera.com ===

Hi sigbjornf@opera.com, 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 : Revert of Expand WTF::StringView's API to be more like StringPiece. (patchset #12 id:220001 of https://codereview.chromium.org/2007103003/ )
Author  : sigbjornf
Commit description:
  
Reason for revert:
Many a heap-buffer-overflow ASan failures,

 https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20ASAN/builds/24329

Original issue's description:
> Expand WTF::StringView's API to be more like StringPiece.
>
> StringView no longer owns the string passed into it, and can now wrap
> a raw ptr to some characters.
>
> This allows us to leverage the inline strlen optimization where the
> compiler will embed the length of literal strings into the binary. It
> also allows the deletion many overloaded methods that used to take
> an LChar*, UChar* or String and can now just take a StringView instead.
>
> For example the two constructors in TextRun are now a single one that
> takes a StringView. This needed to be done in this patch to avoid
> ambiguous constructors.
>
> Future patches will replace CSSParserString with StringView, and also
> vastly simplify the huge number of overloads on various methods. We'll
> also expand the API surface of StringView to include the many useful
> operations that StringPiece has.
>
> BUG= 615174 
>
> Committed: https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582
> Cr-Commit-Position: refs/heads/master@{#396493}

TBR=haraken@chromium.org,jyasskin@chromium.org,yutak@chromium.org,esprehn@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 615174 

Review-Url: https://codereview.chromium.org/2025503002
Cr-Commit-Position: refs/heads/master@{#396641}
Commit  : c70d00665c49b700f2e4f5795044cce1812e6ef9
Date    : Sat May 28 11:53:55 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@396639  22.7916  0.454142  5  good
chromium@396640  22.574   0.681094  5  good
chromium@396641  23.9572  0.490152  5  bad    <--
chromium@396642  23.8656  0.494198  5  bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 616516

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.shadow_dom
Test Metric: SmallDistributionWithLayout/SmallDistributionWithLayout
Relative Change: 4.71%
Score: 99.0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_11_perf_bisect/builds/650
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9011037826052005920


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

| 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!

A revert of something causing UAFs; can't be a perf regression source.

Graph suggests recovery.