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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgworo4woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgwtXCoAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgwpyl9wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggvaqrAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgwtr2ugoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggo2ZgAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgwoTEugoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggs_83QgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggpiyhgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggqe_pwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgwujm5wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgwprVrQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgws6P9woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggs7u-QsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgguvVtgsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggpnc3wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggoOG6AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggtWb9gkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggtih-QgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg_PmJ7wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgwsiH2QsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggoXMkwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggoPIkAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggvn99AsM


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

android-nexus5
android-nexus6
android-nexus7v2
android-webview-nexus6
chromium-rel-mac-retina
chromium-rel-mac11
chromium-rel-mac11-air
chromium-rel-mac11-pro
chromium-rel-mac12
chromium-rel-mac12-mini-8gb
chromium-rel-win7-dual
chromium-rel-win7-x64-dual
chromium-rel-win8-dual
linux-release

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8982022807975916448

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

Hi tkent@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


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

Suspected Commit
  Author : tkent
  Commit : b40e86cfe3be375f082767f2836d5a2ff6b4912b
  Date   : Wed Apr 12 16:02:54 2017
  Subject: Fix attribute matching logic to follow the DOM standard.

Bisect Details
  Configuration: android_nexus7_perf_bisect
  Benchmark    : blink_perf.bindings
  Metric       : get-attribute-rare/get-attribute-rare
  Change       : 17.79% | 40.7879220146 -> 33.5321664358

Revision             Result                   N
chromium@464025      40.7879 +- 1.42422       6      good
chromium@464039      41.5269 +- 1.10688       6      good
chromium@464041      40.8423 +- 2.35258       6      good
chromium@464042      41.2901 +- 1.39343       6      good
chromium@464043      33.2721 +- 1.14775       6      bad       <--
chromium@464046      32.7623 +- 1.36385       6      bad
chromium@464052      33.7308 +- 2.39131       6      bad
chromium@464078      33.5322 +- 0.878321      6      bad

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

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

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


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

My conclusion is that we should accept this slower behavior in order to improve interoperability of attribute matching.

Before my CL, getAttribute() in the test never iterated over string contents, and did pointer-comparison of AtomicStrings.  This was not a conformant behavior because AtomicString("STYLE") should not match to AtomicString("STYLE") in attribute matching.  We need to compare string content or need to iterate over the string content to check if ASCII lower or not at least once.

The test is a micro-benchmark to measure binding layer performance. So slowness of C++ code should not matter.

cc-ing owners of blink_perf.bindings benchmark to make a call on #4

I'm not sure I understand #4. We needed to do case-insensitive comparison before, and we need to do case conversion (possibly -- but in the test case, it's already lowercase "role").

It's not apparent to me why this should be substantially slower.

> It's not apparent to me why this should be substantially slower.

Actually, the difference is very small, but the benchmark is too micro and too sensitive to the small change.