ok, regression was introduced by 4.10.32     https://chromium.googlesource.com/v8/v8/+log/4a8157d1..6adc8c02

bisecting into v8 now

bisected to https://chromium.googlesource.com/v8/v8/+/e709aa24c0c17abf684972fbb9e887731b20fd41

to repro, run the v8.todomvc telemetry benchmark for polymer. On ToT, you can do (after building chrome in release mode)

tools/perf/run_benchmark v8.todomvc --story-filter=Polymer --browser=release

Look for a line RESULT AppLoad-v8_execution_time_total:

I did ten runs and took the average. Before this commit, I get ~100ms, after the commit I get ~150ms

RESULT=$(tools/perf/run_benchmark v8.todomvc --page-repeat=10 --story-filter=Polymer --browser=release |& grep ^RESULT\ AppLoad-v8_execution_time_total:)
echo $(echo $RESULT | sed -e 's/.*\[//'  -e 's/\].*//' -e 's/,/+/g' | bc) / 10 | bc

 Issue 594011  has been merged into this issue.

If the functionality behind the CL is only used behind a flag, can we revert it on M50?

unicode regexp has shipped for m50

Ok, so it was behind a flag when this CL was introduced but on M50 it is on per default. Thanks for clarifying.

The regression however happened when the CL landed, so just flipping the flag wouldn't help anyways

Yes. I thought the feature as a whole is behind a flag in M50 (and thus can also be reverted from M50 as a whole). Obviously this was behind a flag when the culprit CL landed but it was a prerequisite for unicode RegExp. So the options are in order of 'preference':

1.) Fix it
2.) Rip out the whole unicode RegExp implementation
3.) Take the hit

3) is only an option once we understand exactly why this regresses and convinced ourselves that it's not possible to have Unicode regexps without this hit

I havent tried to figure out the cause yet. Will today though.

Something funky is going on.

I can reproduce the regression both here and on  issue 594011 . However, the time we spend on parsing and executing the regexps are negligible and do not seem to cause this regression.

I also traced the regexps patterns and subject strings, and before and after e709aa24, the results are the same, ruling out the possibility that the benchmark simply runs longer because of a different code path triggered by wrong regexp result.

I'll continue investigating.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/25d33be76a2e8e8a6a14b8021b8d16bbce551b6e

commit 25d33be76a2e8e8a6a14b8021b8d16bbce551b6e
Author: yangguo <yangguo@chromium.org>
Date: Mon Mar 21 13:37:35 2016

[regexp] Fix issues with character range limit.

R=jochen@chromium.org
BUG= chromium:595634 
LOG=N

Review URL: https://codereview.chromium.org/1820823003

Cr-Commit-Position: refs/heads/master@{#34938}

[modify] https://crrev.com/25d33be76a2e8e8a6a14b8021b8d16bbce551b6e/src/regexp/jsregexp.cc

Your change meets the bar and is auto-approved for M50 (branch: 2661)

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/f72e279abed9ee8d179b58cb550434740b58f39f

commit f72e279abed9ee8d179b58cb550434740b58f39f
Author: Yang Guo <yangguo@chromium.org>
Date: Tue Mar 22 13:17:42 2016

Version 5.0.71.24 (cherry-pick)

Merged 25d33be76a2e8e8a6a14b8021b8d16bbce551b6e

[regexp] Fix issues with character range limit.

BUG= chromium:595634 
LOG=N
TBR=jochen@chromium.org

Review URL: https://codereview.chromium.org/1825053002 .

Cr-Commit-Position: refs/branch-heads/5.0@{#31}
Cr-Branched-From: ad16e6c2cbd2c6b0f2e8ff944ac245561c682ac2-refs/heads/5.0.71@{#1}
Cr-Branched-From: bd9df50d75125ee2ad37b3d92c8f50f0a8b5f030-refs/heads/master@{#34215}

[modify] https://crrev.com/f72e279abed9ee8d179b58cb550434740b58f39f/include/v8-version.h
[modify] https://crrev.com/f72e279abed9ee8d179b58cb550434740b58f39f/src/regexp/jsregexp.cc

My bug report was merged with this. And the latest Canary does not seem to have this issue! Thanks all. 

Thanks for the confirmation :)