📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16d7c5c1f80000

It looks like the pinpoint job finished but didn't update the bug.
It looks like it has failurs in the second point, and none in the first point but says it found no difference. Not sure what they grey'd out boxes in the second point mean though.

Adding dtu@ for help understanding the pinpoint results. 

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/140aa5e1f80000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12b7d409f80000

It appears what happened is the first pinpoint job that was launched isn't detecting the updated status of the swarming jobs. (I think anyway). The linux one  I launched last seems to be working as expected. 

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/12b7d409f80000

Update ICU to version 60.1 + local patches
By jshin@chromium.org · Wed Nov 08 02:13:24 2017
chromium @ befb16634bb440cf5442979ad262832b4cebd43e

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

select-long-word.html is very artificial and not appeared in usual web pages, e.g.
it select words 196,609 characters long.

It seems Word Breaker in ICU 60 is slower than before but it may be acceptable,
because selecting word is caused by double-click and selecting word can be done
in <100ms and most of words in web page has less than 100.

AFAIK, backward word breaker is slower than before. Current word boundary search
uses backward word breaker, this may cause this performance regression.

As of #c8 of my observation, I think it is OK to mark this bug "Wont Fix".

yosin@: Thanks a lot for your comments/analysis. 

You're spot on. In ICU 60, backward word break is slower unless word-break locations were cached in the previous iteration (forward) because 'backward' rules were removed in rule files. 

In  bug 766816  (ICU update bug), I ran some performance tests(mainly Blink layout tests), but they didn't include this test that got slower. 

Per your comment 8 (and I agree with you about word selection),  I'll mark this as WONTFIX. 

If this test is bad, can you remove the test, then remove the disable connotation before closing this bug? We shouldn't leave bad test code around in our code base.

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/14c88931f80000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/140aa5e1f80000

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

Both of those bisects seem to have been triggered on the wrong benchmark (blink_perf.bindings instead of blink_perf.dom). I kicked off a new bisect on the correct benchmark and am going to submit a CL disabling this story now.

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

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


=== BISECT JOB RESULTS ===
Test failure found with culprit

Suspected Commit
  Author : Jungshik Shin
  Commit : befb16634bb440cf5442979ad262832b4cebd43e
  Date   : Wed Nov 08 02:13:24 2017
  Subject: Update ICU to version 60.1 + local patches

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : blink_perf.dom
  Metric       : select-long-word/select-long-word.html

Revision             Exit Code      N
chromium@514697      0 +- N/A       1      good
chromium@514704      0 +- N/A       1      good
chromium@514708      0 +- N/A       1      good
chromium@514709      1 +- N/A       1      bad       <--
chromium@514710      1 +- N/A       1      bad
chromium@514711      1 +- N/A       1      bad
chromium@514724      1 +- N/A       1      bad
chromium@514750      1 +- N/A       1      bad

Please refer to the following doc on diagnosing blink_perf regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/speed/benchmark_harnesses/blink_perf.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=select.long.word.html blink_perf.dom

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8962932735052768768


For feedback, file a bug with component Speed>Bisection

Unassigning this from jshin@.

Thanks rnephew@ for pointing out that my bisecting didn't really make any sense given the context of this bug: the problem isn't that there's been a performance regression, but rather that we know that there's been a performance regression in a use case that we think is totally unrealistic, prompting nednguyen@ to ask for the removal of the test case.

I'm going to disable the test case and assign this to the benchmark owner to delete the user story.

jbroman@, I just disabled the select-long-word.html story because it was failing. https://bugs.chromium.org/p/chromium/issues/detail?id=783345#c10 seems to suggest that we want to delete this story. Can you reassign to someone on your team to quickly do so?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4afa7ad61172f89244c244ebdfc763fdc3995cbc

commit 4afa7ad61172f89244c244ebdfc763fdc3995cbc
Author: Charlie Andrews <charliea@chromium.org>
Date: Tue Nov 14 21:14:48 2017

Disable blink_perf.dom/select-long.word.html

The story is failing and isn't realistic, so I'm going to disable it
until the benchmark owner can circle around and delete the story.

TBR=rnephew@chromium.org,jbroman@chromium.org

Bug:  783345 
Change-Id: Ieaeca01f6f079add3f571abf81de3187ff9db2e6
Reviewed-on: https://chromium-review.googlesource.com/769158
Reviewed-by: rnephew <rnephew@chromium.org>
Reviewed-by: Charlie Andrews <charliea@chromium.org>
Commit-Queue: Charlie Andrews <charliea@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516427}
[modify] https://crrev.com/4afa7ad61172f89244c244ebdfc763fdc3995cbc/tools/perf/benchmarks/blink_perf.py

Adithya, could you determine what the right course of action is here (it may well be to modify or delete the test, as discussed above) and follow up?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/12cc3cabcca26004d96b435f16df848c76fb48d5

commit 12cc3cabcca26004d96b435f16df848c76fb48d5
Author: Adithya Srinivasan <adithyas@chromium.org>
Date: Mon Nov 20 20:49:33 2017

Remove blink_perf.dom/select-long-word.html

This test case is unrealistic as words are usually never that long.
Slowing down selection of a word this long is acceptable as most words
on a webpage can still be selected in under 100ms.

Bug:  783345 
Change-Id: I55ca93401b94018f45d9a3dbccbe00b9677ab9c1
Reviewed-on: https://chromium-review.googlesource.com/779441
Reviewed-by: Ned Nguyen <nednguyen@google.com>
Commit-Queue: Ned Nguyen <nednguyen@google.com>
Cr-Commit-Position: refs/heads/master@{#517918}
[delete] https://crrev.com/33175057fe267110341b7fda22ab161016e610f7/third_party/WebKit/PerformanceTests/DOM/select-long-word.html
[modify] https://crrev.com/12cc3cabcca26004d96b435f16df848c76fb48d5/tools/perf/benchmarks/blink_perf.py