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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=064cdb077752744ba508bae4239a49868cfe30cf172a09aee1ded3899b3da1c6


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

chromium-rel-win7-gpu-intel
chromium-rel-win7-gpu-nvidia
win-high-dpi

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

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

Hi lwchkg@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 : WC Leung
  Commit : f416f8e8ec6abb5ad2dcc9937315527cd0b49fc9
  Date   : Sat Aug 19 14:50:08 2017
  Subject: Move GetAllProfilesAttributes to ProfileAttributesStorage

Bisect Details
  Configuration: winx64nvidia_perf_bisect
  Benchmark    : startup.cold.blank_page
  Metric       : messageloop_start_time/messageloop_start_time
  Change       : 55.65% | 1549.22222222 -> 2411.33333333

Revision             Result                  N
chromium@495808      1549.22 +- 2487.67      9      good
chromium@495813      1313.67 +- 408.937      6      good
chromium@495815      1537.44 +- 890.498      9      good
chromium@495816      2403.17 +- 1216.11      6      bad       <--
chromium@495817      2411.33 +- 1333.03      9      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests startup.cold.blank_page

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

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


For feedback, file a bug with component Speed>Bisection

The pref regression appears to be caused by the change message_center_settings_controller.cc to execute GetAllProfilesAttributesSortedByName().

That function sorts the items locale-sensitively by ICU, and this can be very expensive. (However, avi@'s comment in chromium@380892 suggest that the sort may be a noop because there should be only 1 item to sort.)

(BTW, that change is a partial revert of refs/heads/master@{#380892}, because of the failure of a test. So reverting is not a good idea.)

Allocating the ICU collation for the sort may also take a lot of time. (Specifically, any reads to icudtl.dat?)

Anyway, the allocation in GetAllProfilesAttributesSortedByName() if there is only one item in the array. I'm not sure if this only moves the time penalty to other parts of Chromium. So further investigation is necessary.

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

commit 0f7a6a96679390d38101b24a27653263c552c7ab
Author: WC Leung <lwchkg@chromium.org>
Date: Sat Sep 02 01:26:53 2017

GetAllProfilesAttributesSortedByName sorts only if necessary

This CL skips the sorting in GetAllProfilesAttributesSortedByName if
there is only one (or zero?) entries in the return.

This should remove some disk reads to the ICU library during startup by
message_center_settings_controller.cc. The disk read appears to cost
an extra second in startup.cold.blank_page in some perf bots. (Still
pending verification in the bots.)

Bug:  760164 
Change-Id: I5ce5fed587ddd26618d474b8356a4132848bec9e
Reviewed-on: https://chromium-review.googlesource.com/641691
Reviewed-by: anthonyvd OoO until september 24th <anthonyvd@chromium.org>
Commit-Queue: WC Leung <lwchkg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#499368}
[modify] https://crrev.com/0f7a6a96679390d38101b24a27653263c552c7ab/chrome/browser/profiles/profile_attributes_storage.cc

There is no more data from startup.cold.blank_page, so I'm unable to follow up on the bug. Whether the patch in #6 fixes the bug is still an unknown.

Reassign to benhenry@ because there appears to be no owner for startup.cold.blank_page.

benhenry@: Could you please take a look on this bug? Anyway, please pass it back to me if there is something concrete that I could do. If not, please either pass to someone else or close the bug. Thanks!

I believe this is no longer something we run.