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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg4dbvrgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg4b2tsgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgoeaBvAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgoYOspwoM


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

chromium-rel-win10
chromium-rel-win7-dual
chromium-rel-win7-x64-dual
chromium-rel-win8-dual

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

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

Hi rogerm@chromium.org, 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 : [Autofill] Declare profile cleanup field trial groups for testing
Author  : rogerm
Commit description:
  
BUG=620414,  640669 

Review-Url: https://codereview.chromium.org/2279543003
Cr-Commit-Position: refs/heads/master@{#415631}
Commit  : f9f54bb9c82589bb0b00c7049b1844f00148db2b
Date    : Wed Aug 31 14:53:59 2016


===== TESTED REVISIONS =====
Revision         Mean    Std Dev  N  Good?
chromium@415622  261.32  29.9989  5  good
chromium@415627  270.56  7.84015  5  good
chromium@415629  244.92  10.8973  5  good
chromium@415630  285.0   18.8685  5  good
chromium@415631  650.88  20.1894  5  bad    <--

Bisect job ran on: winx64_10_perf_bisect
Bug ID: 643356

Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --also-run-disabled-tests startup.cold.blank_page
Test Metric: open_tabs_time/open_tabs_time
Relative Change: 149.07%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/winx64_10_perf_bisect/builds/702
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9002691745084332624


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

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

rogerm, seems your field trial regresses startup. Are you aware of this? What's the launch status of the field trial? Did it regress in the wild as well?

Seems to not be regressing startup significantly in the wild. However, it may still be a true regression in the lab (lower noise).

https://uma.googleplex.com/variations?sid=535c34d593d9cb270d69471b183b77bc

As rschoen mentions, this has no apparent impact in the wild, this might be because it's a one time thing? i.e. for most users it doesn't change anything after doing it once but it slows down the first startup in which it triggers (and on telemetry it's very possible that it triggers every time from whatever test profile is being used)

So we should either:
 1) Fix it to be faster
 2) Eat the one-time slower startup but fix the profiles used by telemetry to be in the migrated state.

+erikchen who knows about telemetry startup profiles

startup.cold.blank_page doesn't use a pre-generated profile, so this sounds like a real, serious bug.

Hmm... I would expect a one-time per major version (on first start post upgrade) hit... but not a hit on an empty start-up profile.

Could this just be the difference between the previous code not querying the db at all vs the new code querying the empty db?

The solution would seem to be to defer running the cleanup until after startup activity as subsided. I'm not sure how best to do that.

Gab, I think you've looked at startup quite a bit. Any hints?

Shouldn't cleanup be a no-op on an empty profile?

Can you use tracing to look at performance on a local machine before/after your change? That should get us a clear idea of the impact of your change.

Alternatively, since the change is only in fieldtrial testing configs, a revert might quickly identify the issue.

Notice: Because of the format change in fieldtrial testing configs, a manual revert is required.

In looking at the code exercised by the fieldtrial, it looks like it misses out on an early exit opportunity. The cleanup is a no-op, but then it triggers a "refresh" to make sure the db and ui are in sync post cleanup.

This *might* be the source of the regression on fresh profile startup.

https://cs.chromium.org/chromium/src/components/autofill/core/browser/personal_data_manager.cc?rcl=1475839200&l=1685

I can skip all of this code if the number of autofill profiles is < 2

Created https://codereview.chromium.org/2398253003/
(early exit if num autofill profiles is less than two)

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

commit 8268475c779cbeabd0446f43b3e91ed0cc18c204
Author: rogerm <rogerm@chromium.org>
Date: Tue Oct 11 16:13:34 2016

Early exit from autofill profile de-duplication if <2 profiles.

We can skip the entire de-decuplication flow if there aren't
multiple autofill profiles to compire to one another.

BUG= 643356 

Review-Url: https://codereview.chromium.org/2398253003
Cr-Commit-Position: refs/heads/master@{#424446}

[modify] https://crrev.com/8268475c779cbeabd0446f43b3e91ed0cc18c204/components/autofill/core/browser/personal_data_manager.cc
[modify] https://crrev.com/8268475c779cbeabd0446f43b3e91ed0cc18c204/components/autofill/core/browser/personal_data_manager.h
[modify] https://crrev.com/8268475c779cbeabd0446f43b3e91ed0cc18c204/components/autofill/core/browser/personal_data_manager_unittest.cc

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

This appears to be fixed (graph has reverted to lower timing). Running bisect job to verify attribution to https://codereview.chromium.org/2398253003 (which is in the CL range)

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

Hi rogerm@chromium.org, 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 : Early exit from autofill profile de-duplication if <2 profiles.
Author  : rogerm
Commit description:
  
We can skip the entire de-decuplication flow if there aren't
multiple autofill profiles to compire to one another.

BUG= 643356 

Review-Url: https://codereview.chromium.org/2398253003
Cr-Commit-Position: refs/heads/master@{#424446}
Commit  : 8268475c779cbeabd0446f43b3e91ed0cc18c204
Date    : Tue Oct 11 16:15:38 2016


===== TESTED REVISIONS =====
Revision         Mean    Std Dev  N  Good?
chromium@424436  1395.2  719.012  5  good
chromium@424443  1310.4  128.972  5  good
chromium@424445  1240.4  199.493  5  good
chromium@424446  266.6   33.3811  5  bad    <--
chromium@424447  310.4   29.0654  5  bad
chromium@424450  296.2   35.8427  5  bad
chromium@424464  274.6   26.0154  5  bad
chromium@424491  306.4   19.5013  5  bad

Bisect job ran on: win_8_perf_bisect
Bug ID: 643356

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests startup.cold.blank_page
Test Metric: open_tabs_time/open_tabs_time
Relative Change: 78.04%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_8_perf_bisect/builds/2248
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8998453792908486000


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

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

If I'm reading the bisect status update correctly, it confirms that the CL fixes the problem (by "regressing" down to 78% of the previous startup time).

Marking as fixed.

Yup, thanks for fixing this!