New issue
Advanced search Search tips

Issue 787983 link

Starred by 15 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature


Sign in to add a comment

Chrome should build faster on Windows

Project Member Reported by brucedaw...@chromium.org, Nov 22 2017

Issue description

This bug tracks all efforts to make building Chrome for Windows faster. We have instructions for how to optimize your build:

https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Faster-builds

These build instructions will be updated next week after we have the clang launch review meeting.

However Chrome for Windows still takes an annoyingly long time to build, especially for those without access to goma. So, I'm making this the master bug for tracking most efforts to make Chrome build faster. Other bugs will be marked as blocking this one. At the moment we have:

crbug.com/725639 - Component builds restrict build parallelism, costing 60-120 seconds on a full build
crbug.com/610459 - Link parallelism needs adjustment to avoid OOM while maximizing parallelism
 crbug.com/679089  - See if incremental linking can be enabled for x64 in goma/symbol_level=1 builds
crbug.com/746956 - [META] Compile Chromium with jumbo
crbug.com/774674 - Local Windows Clang builds are 60% slower than VC
crbug.com/766721 - Consider switching from yasm to nasm; it's better maintained and much faster.
crbug.com/663220 - Changing linker settings causes excessive compilation
crbug.com/495204 - Make it possible to build chrome/win on linux, using clang-cl and gn
 crbug.com/787695  - Non deterministic generated files
 crbug.com/773144  - Get v8_context_snapshot_generator out of critical build path
crbug.com/429328 - Shared release builds with clang/win are much slower (possible clang optimization)

These two bugs overlap significantly:
crbug.com/787903 - Python CPU usage on chrome builds is significant
crbug.com/773138 - python wrapper for C compiler costs lots of CPU cycles

So, lots of possibilities for improving build speeds, or at least slowing the increase.

Also relevant (but not really "blocking) is crbug.com/709690- Use Clang for Windows builds

This bug has restricted access but I'm linking it here anyway.

crbug.com/702518 - Increase link parallelism for win buildbot with is_component_build=true - many compilation steps wait on link steps that they don't need to link on, this can be seen when looking at ninjatracing reports where the compile stages all 'drain' before many of the link steps, leading to excessive serialization and wasted time.

This supersedes the restricted-access bugs crbug.com/495670.

 
Issue 495670 has been merged into this issue.

Comment 2 by vapier@chromium.org, Nov 23 2017

Blockedon: -773138
Blockedon: 791442
Project Member

Comment 4 by bugdroid1@chromium.org, Dec 9 2017

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

commit 396e35d38515d055988c7ad3d3ea43d68769b91f
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Sat Dec 09 18:08:40 2017

Adjust jumbo_file_merge_limit for goma

Jumbo builds reduce the total amount of CPU time used for compilation,
but they reduce parallelism. On machines with a modest number of cores
this is pure win, but on massively parallel builds this reduces the
benefits of jumbo. This change tweaks jumbo_file_merge_limit to a much
lower number when doing goma builds. This should also improve the
performance of incremental builds.

Testing was done with various merge limits while building chrome and
webkit_unit_tests and 8 was found to give the best combination of
elapsed-time full build performance and incremental build performance.
As expected the total CPU time spend compiling (and linking) goes up
when using a lower jumbo_file_merge_limit, but the wall clock time drops
(on goma builds). A merge limit of 10 may give slightly faster full
builds, but risks longer incremental builds. The exact number is not
critical but this is definitely in the right range, and much better than
the default of 50.

Testing suggests that jumbo goma builds will now take about 20% less
time than non-jumbo goma builds. goma builds with the old jumbo settings
were somewhere in-between. Results will improve as jumbo grows.

All testing was done on Windows with clang and is assumed to be
sufficiently applicable to other platforms.

Bug: 787983
Change-Id: I4e26341a5b224011d1401efa4563fcf2b53c969c
Reviewed-on: https://chromium-review.googlesource.com/814896
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523004}
[modify] https://crrev.com/396e35d38515d055988c7ad3d3ea43d68769b91f/build/config/jumbo.gni

This could also help improve performance. In some cases (especially when anti-virus intrudes) process creation can be slow on Windows and ninja's process creation is serialized. This issue should be investigated and addressed:

ninja process creation should be multi-threaded - https://github.com/ninja-build/ninja/issues/1246

Comment 6 by tikuta@chromium.org, Dec 18 2017

Cc: tikuta@chromium.org
Blockedon: 796269
Blockedon: 796021
Owner: brucedaw...@chromium.org
Status: Assigned (was: Untriaged)
Project Member

Comment 10 by bugdroid1@chromium.org, Feb 9 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/depot_tools/+/ffc0c7c691582e4cfbad44b71b3de5e9d36f6ec8

commit ffc0c7c691582e4cfbad44b71b3de5e9d36f6ec8
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Fri Feb 09 21:41:49 2018

Script to summarize performance of ninja builds

post_build_ninja_summary.py analyzes the .ninja_log file in an output
directory to summarize build performance. It lists the most expensive
build steps, and build-step types, printing both their elapsed time and,
more importantly, their "weighted" time which is a measure of their
contribution to the total build time.

For each time segment within the build the running build steps
accumulate weighted time that is proportional to the elapsed time
divided by the number of tasks running. If a thousand compilation steps
are running in parallel then they will each be "charged" for 1/1,000th
of the elapsed time. If a single link step is running alone then it is
charged with all of the elapsed time.

Bug: chromium:787983
Change-Id: Id5aea715f798a16415dd0365a27f0051202668e5
Reviewed-on: https://chromium-review.googlesource.com/871988
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Erik Staab <estaab@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>

[modify] https://crrev.com/ffc0c7c691582e4cfbad44b71b3de5e9d36f6ec8/autoninja.bat
[add] https://crrev.com/ffc0c7c691582e4cfbad44b71b3de5e9d36f6ec8/post_build_ninja_summary.py

Project Member

Comment 11 by bugdroid1@chromium.org, Feb 13 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/depot_tools/+/46541b4996f25b706146148331b9613c8a787e7e

commit 46541b4996f25b706146148331b9613c8a787e7e
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Tue Feb 13 20:47:20 2018

Fix autoninja && chrome on failed builds

A handy usage pattern for autoninja.bat that I was not aware of is to go

    autoninja -C out\Default chrome && chrome

This will build chrome and then run it, but only run it if the build
succeeds. The addition of post_build_ninja_summary.py broke this by
losing the error code. This change fixes it by using black magic to
set an error code in the failure case.

Bug: chromium:787983
Change-Id: Ib87fd1799816e19d56de76e08e0f9688be903d80
Reviewed-on: https://chromium-review.googlesource.com/916705
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>

[modify] https://crrev.com/46541b4996f25b706146148331b9613c8a787e7e/autoninja.bat
[modify] https://crrev.com/46541b4996f25b706146148331b9613c8a787e7e/autoninja

Components: Build
Project Member

Comment 13 by bugdroid1@chromium.org, Mar 3 2018

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

commit e9f20fff8f265370a2ce78f47d87f8cc5c1a2182
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Sat Mar 03 01:58:38 2018

Clean up build/build-speed instructions

The switch to clang-cl has made many of the build instructions incorrect
or misleading, and some build-speed tips are sorely needed.

Cleanups include:
- Correct the SDK requirements (FCU SDK doesn't work)
- Clarify that VS is still needed even though we compile with clang-cl
- Correct goma instructions and recommend it more strongly
- Update linker options for the clang-cl world
- Add troubleshooting instructions for slow builds including
NINJA_STATUS, NINJA_SUMMARIZE_BUILD, ninjatracing, and -d stats.

The results were tested with both https://dillinger.io/ and
python tools/md_browser/md_browser.py docs\windows_build_instructions.md
since neither one gives 100% correct results.

Bug: 787983
Change-Id: Ic0d16d884439723dfb3feb610892d7e667e7ae3a
Reviewed-on: https://chromium-review.googlesource.com/947573
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540716}
[modify] https://crrev.com/e9f20fff8f265370a2ce78f47d87f8cc5c1a2182/docs/windows_build_instructions.md

Project Member

Comment 14 by bugdroid1@chromium.org, Mar 6 2018

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

commit 0bbe2d46832dbd66994722112c866e455e1189e7
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Tue Mar 06 19:45:55 2018

Tweaks to windows build instructions

anti-virus -> antivirus
Add instructions on running post_build_ninja_summary.py manually.

Bug: 787983
Change-Id: I2f44b292fb80d1cac56d4c2b1cbe9d65ff6fd7e1
Reviewed-on: https://chromium-review.googlesource.com/949416
Reviewed-by: Xi Cheng <chengx@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541175}
[modify] https://crrev.com/0bbe2d46832dbd66994722112c866e455e1189e7/docs/windows_build_instructions.md

Blockedon: 819319
Project Member

Comment 16 by bugdroid1@chromium.org, Jun 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/depot_tools/+/6be8afd57a12883e5dbb210124e0f9e14f639d00

commit 6be8afd57a12883e5dbb210124e0f9e14f639d00
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Mon Jun 11 20:00:05 2018

Improve post_build_ninja_summary.py's incremental build handling

post_build_ninja_summary.py detects a new incremental build by looking
for the end time stamps to go backwards. This means that repeated builds
that have a single long step will not be reliably detected and will, in
some cases, be missed entirely. This hits me sometimes when doing link
testing - delete an output DLL, rebuild, and the old results may be
displayed again.

This change updates the script to check for a different duration for an
existing record as well as an earlier end time should handle almost all
cases.

This also renames the targets local variable to avoid confusion due
to the targets member variable of the Targets class.

Bug: chromium:787983
Change-Id: I60a371df75d6cb7a55bd46b38156cb109feb8f15
Reviewed-on: https://chromium-review.googlesource.com/1061413
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>

[modify] https://crrev.com/6be8afd57a12883e5dbb210124e0f9e14f639d00/post_build_ninja_summary.py

Project Member

Comment 17 by bugdroid1@chromium.org, Jun 12 2018

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

commit ba76c5f5dbec374e50a9efdbba41974a1afaf826
Author: depot-tools-chromium-autoroll <depot-tools-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Date: Tue Jun 12 07:10:15 2018

Roll src/third_party/depot_tools a10370c44be8..b63c4663d478 (4 commits)

https://chromium.googlesource.com/chromium/tools/depot_tools.git/+log/a10370c44be8..b63c4663d478


git log a10370c44be8..b63c4663d478 --date=short --no-merges --format='%ad %ae %s'
2018-06-11 ehmaldonado@chromium.org gclient: Use only recursedeps to decide whether to process a dependency (Trigger recipe roller)
2018-06-11 ehmaldonado@chromium.org gclient: Use only recursedeps to decide whether to process a dependency.
2018-06-11 brucedawson@chromium.org Improve post_build_ninja_summary.py's incremental build handling
2018-06-11 recipe-roller@chromium.org Roll recipe dependencies (trivial).


Created with:
  gclient setdep -r src/third_party/depot_tools@b63c4663d478

The AutoRoll server is located here: https://depot-tools-chromium-roll.skia.org

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.



BUG=chromium:839925,chromium:839925,chromium:787983
TBR=agable@chromium.org

Change-Id: I067bdf689595ed16809b3cd667c29b62b71e5798
Reviewed-on: https://chromium-review.googlesource.com/1096219
Reviewed-by: depot-tools-chromium-autoroll <depot-tools-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: depot-tools-chromium-autoroll <depot-tools-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#566345}
[modify] https://crrev.com/ba76c5f5dbec374e50a9efdbba41974a1afaf826/DEPS

Sign in to add a comment