New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 617837 link

Starred by 0 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocking:
issue 354261



Sign in to add a comment

Building win_chromium_rel_ng with GN is too slow

Project Member Reported by dpranke@chromium.org, Jun 7 2016

Issue description

Currently we're over the allotted cycle time for CQ bots (compile time for win_chromium_rel_ng is close to an hour, total cycle time is close to 85 min). 

It looks like GN is significantly slower than GYP for reasons we don't yet understand.

I'm going to flip the builder back to GYP, and we can use this bug to track getting it back onto GN and inside the SLO.

We should treat this as very high priority since most of the other windows bots are now on GN and we want to ship GN in the next release.
 
Project Member

Comment 1 by bugdroid1@chromium.org, Jun 7 2016

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

commit 535e76ffb990fe6fc4f5babd70ba9c020a1e3bf9
Author: dpranke <dpranke@chromium.org>
Date: Tue Jun 07 02:53:06 2016

Flip win_chromium_rel_ng back to GYP, re-add win8_chromium_ng to CQ.

This CL reverts r397982 ( https://codereview.chromium.org/2032613004 )
and also flips the main win CQ bots back to GYP. This will hopefully
get the cycle time and capacity issues for the CQ back under control.

TBR=brucedawson@chromium.org, phajdan.jr@chromium.org
BUG= 617837 

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

[modify] https://crrev.com/535e76ffb990fe6fc4f5babd70ba9c020a1e3bf9/infra/config/cq.cfg
[modify] https://crrev.com/535e76ffb990fe6fc4f5babd70ba9c020a1e3bf9/testing/buildbot/chromium.win.json
[modify] https://crrev.com/535e76ffb990fe6fc4f5babd70ba9c020a1e3bf9/tools/mb/mb_config.pyl

Blockedon: 618066
Moving some data from the email conversation...

I looked at the build steps for build 44073 (last gyp build before switching) and build 44075 (second gn build after switching, leaving time for caches to adjust?) - build results are here:

https://build.chromium.org/p/chromium/builders/Win/builds/44073
https://build.chromium.org/p/chromium/builders/Win/builds/44075

The slowest build steps for 44075 (gn) are listed below - the numbers in parentheses are how long the same build step took on the 44073 (gyp) build. This is a clobber builder so the results should be *fairly* consistent and meaningful. The time differences are sometimes quite huge.

GYP settings:
GYP_DEFINES=test_isolation_mode=noop component=static_library use_goma=1 fastbuild=1 target_arch=ia32 gomadir='C:\b\build\slave\cache\cipd\goma'

GN settings:
is_component_build = false
is_debug = false
symbol_level = 1
target_cpu = "x86"
use_goma = true

  83.770 (   9.792): blink_platform_unittests.exe - does not repro locally, fast for both, see below
  92.187 (  63.999): next_version_mini_installer.exe
 144.042 (  34.216): components_perftests.exe
 145.309 (  24.514): blink_heap_unittests.exe
 146.125 (  43.220): content_shell.exe
 147.863 (  37.017): content_perftests.exe
 152.958 (  44.911): content_browsertests.exe
 154.651 (  38.273): app_list_demo.exe
 157.883 (  47.801): components_browsertests.exe
 159.301 (  31.369): webkit_unit_tests.exe
 159.355 (   8.219): ash_unittests.exe
 159.464 (  25.287): ash_shell_with_content.exe
 159.961 (  42.587): views_examples_with_content_exe.exe
 161.269 (  38.643): app_shell.exe
 162.457 (  48.765): content_unittests.exe
 164.243 (  40.122): extensions_unittests.exe
 165.164 (  34.142): app_shell_unittests.exe
 165.395 (  35.828): extensions_browsertests.exe
 170.840 (  36.676): chrome_child.dll
 173.346 (   9.693): load_library_perf_tests.exe - reproed locally, fixed with crrev.com/2048783002
 173.850 (   4.854): chrome_app_unittests.exe - reproed locally, 3.7 s for gyp and 183.2 s for gn
 174.616 (  20.807): chrome.dll - does not repro locally, slow for both, see below
 176.199 (  63.254): performance_browser_tests.exe
 177.967 (  56.984): sync_integration_tests.exe
 178.067 (  56.852): sync_performance_tests.exe
 179.229 (  67.273): interactive_ui_tests.exe
 192.164 (  63.833): components_unittests.exe
 192.995 (  49.696): browser_tests.exe
 199.225 (  76.729): unit_tests.exe

My local build is a component debug build and one of those differences must explain why some of the behavior does not repro locally yet.

The load_library_perf_tests.exe link caused the linker's private working set to grow to about 6.5 GB which, if happening in multiple links, can lead to additional slowdowns elsewhere. The fix avoids that memory growth.
I switched my local build to match the win_chromium_rel_ng settings (except I didn't use goma) and I now see only a 10-15% increase in build times for gn builds versus gyp builds. This is without the CDM test constants fix for load_library_perf_test (crrev.com/2048783002) and without the fix to use more static libraries (crrev.com/2043873004).

In particular I see that the time for .obj targets in the gn builds is only 4.9% longer than the time for .obj targets in the gyp builds, despite there being 14.3% more targets. That is, time-per-file was lower for gn than for gyp. I'm not clear on why the gn build has 14.3% more .obj targets, and why it also has 3,359 .o targets.

My best guess is that the slowdown is because the memory-hungry links were causing everything to run more slowly. Therefore crrev.com/2043873004 should address the problem. If not then I will have to do tests with goma compilation to see how that affects things.
The .o files are due to nacl being part of the "normal" build in gn instead of all of nacl being built by a handful of python build_nexe.py files in the gyp build. This also explains much of the additional targets (the other bit is that a bunch of mojo stuff is gn-only)
Got it. That explains why the gyp builds have just as many (actually more) .o files created, and it explains why the gyp builds have enormous .a build steps - totaling 5253 s on my local tests compared to 4053 for the .o build steps in gn.

Comment 7 by jam@chromium.org, Jun 8 2016

re comment 4: while we can use local builds for testing speedups, we need to use trybots for getting accurate numbers of slowdowns. i.e. we have 64GB ram while the bots have 16, and that influences the number of concurrent links. Also we need times with goma turned on. Basically, since the thing that we care about is trybot build speed, let's get numbers from there :)
Project Member

Comment 8 by bugdroid1@chromium.org, Jun 11 2016

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

commit 000e11f48c6a4b2540a4b9fcae87b839d1e64117
Author: brettw <brettw@chromium.org>
Date: Sat Jun 11 01:47:18 2016

Make large test_support targets static libraries.

On Windows this seems to make some tests link faster because the tests link to these larget targets but don't use most of them. The static library is much more efficient to link in this case since only the required compilation units are loaded.

TBR=dpranke
(split off of https://codereview.chromium.org/2043873004/ which already has review)
BUG= 617837 

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

[modify] https://crrev.com/000e11f48c6a4b2540a4b9fcae87b839d1e64117/chrome/common/BUILD.gn
[modify] https://crrev.com/000e11f48c6a4b2540a4b9fcae87b839d1e64117/chrome/test/BUILD.gn
[modify] https://crrev.com/000e11f48c6a4b2540a4b9fcae87b839d1e64117/content/test/BUILD.gn

Project Member

Comment 9 by bugdroid1@chromium.org, Jun 13 2016

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

commit 2f95a3fb1773f911ca05c26cbacaecc537bd9e31
Author: brettw <brettw@chromium.org>
Date: Mon Jun 13 01:03:17 2016

Make chrome/browser and .../ui static libraries.

On Windows this seems to make some tests link faster because the tests link to these larget targets but don't use most of them. The static library is much more efficient to link in this case since only the required compilation units are loaded.

TBR=dpranke
(split off of https://codereview.chromium.org/2043873004/ which already has review)
BUG= 617837 

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

[modify] https://crrev.com/2f95a3fb1773f911ca05c26cbacaecc537bd9e31/chrome/browser/BUILD.gn
[modify] https://crrev.com/2f95a3fb1773f911ca05c26cbacaecc537bd9e31/chrome/browser/ui/BUILD.gn

Project Member

Comment 10 by bugdroid1@chromium.org, Jun 13 2016

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

commit 3b678169f32f46b0bab203bfd0572fad1c314ab7
Author: brettw <brettw@chromium.org>
Date: Mon Jun 13 03:28:31 2016

Default components to static libraries in GN build

Previously components would be source sets in non-component mode. Some test targets link large components in chrome but use almost none of them, and including all object files makes these links very slow.

BUG= 617837 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/3b678169f32f46b0bab203bfd0572fad1c314ab7/base/BUILD.gn
[modify] https://crrev.com/3b678169f32f46b0bab203bfd0572fad1c314ab7/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/3b678169f32f46b0bab203bfd0572fad1c314ab7/chrome/browser/BUILD.gn

Project Member

Comment 11 by bugdroid1@chromium.org, Jun 13 2016

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

commit 7395734b45799a2bc04f54b8a932db259314faac
Author: fmeawad <fmeawad@chromium.org>
Date: Mon Jun 13 16:02:27 2016

Revert of Make chrome/browser and .../ui static libraries. (patchset #2 id:20001 of https://codereview.chromium.org/2063483002/ )

Reason for revert:
Breaking Win x64 Perf builder (official)

Speculative.

BUG= 619606 

Original issue's description:
> Make chrome/browser and .../ui static libraries.
>
> On Windows this seems to make some tests link faster because the tests link to these larget targets but don't use most of them. The static library is much more efficient to link in this case since only the required compilation units are loaded.
>
> TBR=dpranke
> (split off of https://codereview.chromium.org/2043873004/ which already has review)
> BUG= 617837 
>
> Committed: https://crrev.com/2f95a3fb1773f911ca05c26cbacaecc537bd9e31
> Cr-Commit-Position: refs/heads/master@{#399401}

TBR=dpranke@google.com,brettw@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 617837 

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

[modify] https://crrev.com/7395734b45799a2bc04f54b8a932db259314faac/chrome/browser/BUILD.gn
[modify] https://crrev.com/7395734b45799a2bc04f54b8a932db259314faac/chrome/browser/ui/BUILD.gn

Project Member

Comment 12 by bugdroid1@chromium.org, Jun 13 2016

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

commit da29fd813a852c3b08db7e065b860fc0c2e64028
Author: zhenw <zhenw@chromium.org>
Date: Mon Jun 13 17:17:23 2016

Revert of Default components to static libraries in GN build (patchset #15 id:280001 of https://codereview.chromium.org/2043873004/ )

Reason for revert:
This CL causes Win x64 Builder (Perf) compilation error:

FAILED: obj/third_party/WebKit/Source/modules/blink_modules.lib
C:/b/depot_tools/python276_bin/python.exe gyp-win-tool link-wrapper environment.x64 False lib.exe /nologo /ignore:4221 /LTCG /LTCG /LTCG /LTCG /OUT:obj/third_party/WebKit/Source/modules/blink_modules.lib @obj/third_party/WebKit/Source/modules/blink_modules.lib.rsp
obj/third_party/WebKit/Source/modules/blink_modules.lib : fatal error LNK1248: image size (10061341C) exceeds maximum allowable size (FFFFFFFF)

[791/850] LINK(DLL) mus_library.dll mus_library.dll.lib
[792/850] LINK cc_perftests.exe
ninja: build stopped: subcommand failed.

Also see  http://crbug.com/619606 .

Original issue's description:
> Default components to static libraries in GN build
>
> Previously components would be source sets in non-component mode. Some test targets link large components in chrome but use almost none of them, and including all object files makes these links very slow.
>
> BUG= 617837 
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
>
> Committed: https://crrev.com/3b678169f32f46b0bab203bfd0572fad1c314ab7
> Cr-Commit-Position: refs/heads/master@{#399406}

TBR=jam@chromium.org,brucedawson@chromium.org,brettw@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 617837 

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

[modify] https://crrev.com/da29fd813a852c3b08db7e065b860fc0c2e64028/base/BUILD.gn
[modify] https://crrev.com/da29fd813a852c3b08db7e065b860fc0c2e64028/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/da29fd813a852c3b08db7e065b860fc0c2e64028/chrome/browser/BUILD.gn

This build break (LNK1248) makes sense in retrospect...

Windows .lib files have a 4 GB limit. GYP gets around this using msvs_shard (see crrev.com/1842203003 for one example) which is a tag that can be applied to automatically break a library up into multiple pieces. Source sets make this tag unnecessary with gn, but the limitations of source sets (increased link times in some contexts) means that msvs_shard is now needed.

Sigh...

The limit used to be 2 GB and now appears to be 4 GB so that may give us some more head room and reduce the number of libraries that need this hack. Maybe.

I am switching back to source sets for official builds.
Project Member

Comment 15 by bugdroid1@chromium.org, Jun 14 2016

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

commit 022f8f346d72007cf75469299f894ad4edfda5a8
Author: brettw <brettw@chromium.org>
Date: Tue Jun 14 01:22:39 2016

Default components to static libraries in GN build

Previously components would be source sets in non-component mode. Some test targets link large components in chrome but use almost none of them, and including all object files makes these links very slow.

Reland of https://codereview.chromium.org/2043873004/ and https://codereview.chromium.org/2063483002 but disabled for official Windows builds.

In support of the official condition, is_official_build moved to BUILDCONFIG. Since this is really a different level of debug/release, this may actually make more sense. The documentation around this was enhanced a lot, official now automatically turns off debug, and it will assert if you override both to produce an official debug build.

BUG= 617837 

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

[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/base/BUILD.gn
[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/build/config/chrome_build.gni
[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/chrome/browser/BUILD.gn
[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/chrome/browser/ui/BUILD.gn

Project Member

Comment 16 by bugdroid1@chromium.org, Jun 14 2016

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

commit 21742f893ef0a3074ba1cf113b5c0e6c42bf0f7e
Author: dpranke <dpranke@chromium.org>
Date: Tue Jun 14 20:16:01 2016

Flip win_chromium_rel_ng to GN, remove win8_chromium_ng from the CQ.

This commit reverts r398210 and re-lands r397982 (more or less).

R=brettw@chromium.org
BUG= 617837 

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

[modify] https://crrev.com/21742f893ef0a3074ba1cf113b5c0e6c42bf0f7e/infra/config/cq.cfg
[modify] https://crrev.com/21742f893ef0a3074ba1cf113b5c0e6c42bf0f7e/testing/buildbot/chromium.win.json
[modify] https://crrev.com/21742f893ef0a3074ba1cf113b5c0e6c42bf0f7e/tools/mb/mb_config.pyl

Project Member

Comment 17 by bugdroid1@chromium.org, Jun 15 2016

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

commit 000e11f48c6a4b2540a4b9fcae87b839d1e64117
Author: brettw <brettw@chromium.org>
Date: Sat Jun 11 01:47:18 2016

Make large test_support targets static libraries.

On Windows this seems to make some tests link faster because the tests link to these larget targets but don't use most of them. The static library is much more efficient to link in this case since only the required compilation units are loaded.

TBR=dpranke
(split off of https://codereview.chromium.org/2043873004/ which already has review)
BUG= 617837 

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

[modify] https://crrev.com/000e11f48c6a4b2540a4b9fcae87b839d1e64117/chrome/common/BUILD.gn
[modify] https://crrev.com/000e11f48c6a4b2540a4b9fcae87b839d1e64117/chrome/test/BUILD.gn
[modify] https://crrev.com/000e11f48c6a4b2540a4b9fcae87b839d1e64117/content/test/BUILD.gn

Project Member

Comment 18 by bugdroid1@chromium.org, Jun 15 2016

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

commit 2f95a3fb1773f911ca05c26cbacaecc537bd9e31
Author: brettw <brettw@chromium.org>
Date: Mon Jun 13 01:03:17 2016

Make chrome/browser and .../ui static libraries.

On Windows this seems to make some tests link faster because the tests link to these larget targets but don't use most of them. The static library is much more efficient to link in this case since only the required compilation units are loaded.

TBR=dpranke
(split off of https://codereview.chromium.org/2043873004/ which already has review)
BUG= 617837 

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

[modify] https://crrev.com/2f95a3fb1773f911ca05c26cbacaecc537bd9e31/chrome/browser/BUILD.gn
[modify] https://crrev.com/2f95a3fb1773f911ca05c26cbacaecc537bd9e31/chrome/browser/ui/BUILD.gn

Project Member

Comment 19 by bugdroid1@chromium.org, Jun 15 2016

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

commit 3b678169f32f46b0bab203bfd0572fad1c314ab7
Author: brettw <brettw@chromium.org>
Date: Mon Jun 13 03:28:31 2016

Default components to static libraries in GN build

Previously components would be source sets in non-component mode. Some test targets link large components in chrome but use almost none of them, and including all object files makes these links very slow.

BUG= 617837 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/3b678169f32f46b0bab203bfd0572fad1c314ab7/base/BUILD.gn
[modify] https://crrev.com/3b678169f32f46b0bab203bfd0572fad1c314ab7/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/3b678169f32f46b0bab203bfd0572fad1c314ab7/chrome/browser/BUILD.gn

Project Member

Comment 20 by bugdroid1@chromium.org, Jun 15 2016

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

commit 7395734b45799a2bc04f54b8a932db259314faac
Author: fmeawad <fmeawad@chromium.org>
Date: Mon Jun 13 16:02:27 2016

Revert of Make chrome/browser and .../ui static libraries. (patchset #2 id:20001 of https://codereview.chromium.org/2063483002/ )

Reason for revert:
Breaking Win x64 Perf builder (official)

Speculative.

BUG= 619606 

Original issue's description:
> Make chrome/browser and .../ui static libraries.
>
> On Windows this seems to make some tests link faster because the tests link to these larget targets but don't use most of them. The static library is much more efficient to link in this case since only the required compilation units are loaded.
>
> TBR=dpranke
> (split off of https://codereview.chromium.org/2043873004/ which already has review)
> BUG= 617837 
>
> Committed: https://crrev.com/2f95a3fb1773f911ca05c26cbacaecc537bd9e31
> Cr-Commit-Position: refs/heads/master@{#399401}

TBR=dpranke@google.com,brettw@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 617837 

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

[modify] https://crrev.com/7395734b45799a2bc04f54b8a932db259314faac/chrome/browser/BUILD.gn
[modify] https://crrev.com/7395734b45799a2bc04f54b8a932db259314faac/chrome/browser/ui/BUILD.gn

Project Member

Comment 21 by bugdroid1@chromium.org, Jun 15 2016

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

commit da29fd813a852c3b08db7e065b860fc0c2e64028
Author: zhenw <zhenw@chromium.org>
Date: Mon Jun 13 17:17:23 2016

Revert of Default components to static libraries in GN build (patchset #15 id:280001 of https://codereview.chromium.org/2043873004/ )

Reason for revert:
This CL causes Win x64 Builder (Perf) compilation error:

FAILED: obj/third_party/WebKit/Source/modules/blink_modules.lib
C:/b/depot_tools/python276_bin/python.exe gyp-win-tool link-wrapper environment.x64 False lib.exe /nologo /ignore:4221 /LTCG /LTCG /LTCG /LTCG /OUT:obj/third_party/WebKit/Source/modules/blink_modules.lib @obj/third_party/WebKit/Source/modules/blink_modules.lib.rsp
obj/third_party/WebKit/Source/modules/blink_modules.lib : fatal error LNK1248: image size (10061341C) exceeds maximum allowable size (FFFFFFFF)

[791/850] LINK(DLL) mus_library.dll mus_library.dll.lib
[792/850] LINK cc_perftests.exe
ninja: build stopped: subcommand failed.

Also see  http://crbug.com/619606 .

Original issue's description:
> Default components to static libraries in GN build
>
> Previously components would be source sets in non-component mode. Some test targets link large components in chrome but use almost none of them, and including all object files makes these links very slow.
>
> BUG= 617837 
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
>
> Committed: https://crrev.com/3b678169f32f46b0bab203bfd0572fad1c314ab7
> Cr-Commit-Position: refs/heads/master@{#399406}

TBR=jam@chromium.org,brucedawson@chromium.org,brettw@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 617837 

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

[modify] https://crrev.com/da29fd813a852c3b08db7e065b860fc0c2e64028/base/BUILD.gn
[modify] https://crrev.com/da29fd813a852c3b08db7e065b860fc0c2e64028/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/da29fd813a852c3b08db7e065b860fc0c2e64028/chrome/browser/BUILD.gn

Project Member

Comment 22 by bugdroid1@chromium.org, Jun 15 2016

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

commit 022f8f346d72007cf75469299f894ad4edfda5a8
Author: brettw <brettw@chromium.org>
Date: Tue Jun 14 01:22:39 2016

Default components to static libraries in GN build

Previously components would be source sets in non-component mode. Some test targets link large components in chrome but use almost none of them, and including all object files makes these links very slow.

Reland of https://codereview.chromium.org/2043873004/ and https://codereview.chromium.org/2063483002 but disabled for official Windows builds.

In support of the official condition, is_official_build moved to BUILDCONFIG. Since this is really a different level of debug/release, this may actually make more sense. The documentation around this was enhanced a lot, official now automatically turns off debug, and it will assert if you override both to produce an official debug build.

BUG= 617837 

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

[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/base/BUILD.gn
[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/build/config/chrome_build.gni
[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/chrome/browser/BUILD.gn
[modify] https://crrev.com/022f8f346d72007cf75469299f894ad4edfda5a8/chrome/browser/ui/BUILD.gn

Project Member

Comment 23 by bugdroid1@chromium.org, Jun 15 2016

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

commit 21742f893ef0a3074ba1cf113b5c0e6c42bf0f7e
Author: dpranke <dpranke@chromium.org>
Date: Tue Jun 14 20:16:01 2016

Flip win_chromium_rel_ng to GN, remove win8_chromium_ng from the CQ.

This commit reverts r398210 and re-lands r397982 (more or less).

R=brettw@chromium.org
BUG= 617837 

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

[modify] https://crrev.com/21742f893ef0a3074ba1cf113b5c0e6c42bf0f7e/infra/config/cq.cfg
[modify] https://crrev.com/21742f893ef0a3074ba1cf113b5c0e6c42bf0f7e/testing/buildbot/chromium.win.json
[modify] https://crrev.com/21742f893ef0a3074ba1cf113b5c0e6c42bf0f7e/tools/mb/mb_config.pyl

Project Member

Comment 24 by bugdroid1@chromium.org, Jun 17 2016

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

commit c7bbafa2ad385b444f5bd2125c95920c528e946e
Author: dpranke <dpranke@chromium.org>
Date: Fri Jun 17 03:02:05 2016

Change 'chromium_builder_tests' to be empty in GN builds.

This was previous defined as a synonym for 'All', but using that
was causing things to be built unnecessarily on the builders, and
we're too close to the cycle time limit in the commit queue.

Really, we shouldn't ever be using this target anyway; builders should
either be building 'all' or a more specific list of targets rather
than some arbitrary grouping of stuff.

TBR=jam@chromium.org, brucedawson@chromium.org, brettw@chromium.org
BUG= 617837 

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

[modify] https://crrev.com/c7bbafa2ad385b444f5bd2125c95920c528e946e/BUILD.gn

Blocking: 354261
Blocking: -605318
Blockedon: -618066
Status: Fixed (was: Started)
I think the issues w/ the CQ have been addressed. The underlying `analyze` issue remains, but we can track that bug separately to avoid confusing things.

Sign in to add a comment