Scripts for unity/jumbo (default disabled) compilation

Scripts for unity/jumbo (default disabled) compilation.

To speed up compilation times, jumbo allows files to be compiled
together. This is a well known method ("unity builds") to both
compile faster and create a poor man's "full program optimization".
For Chromium we are only interested in the compile times.

This patch includes the basic scripts that do the source file merging
and changes Blink Core to use those scripts. If the gn configuration
includes: use_jumbo_build = true then Blink Core will use jumbo
compile. Otherwise it will compile as usual.

The expected speedup from using Jumbo on Blink Core (and nothing else)
is about 17% of the content_shell+blink_tests compilation CPU
time. This is about half an hour for people building with an ordinary
computer, but less both in percentage and minutes if using some kind
of build accelerator like goma.

More information in
https://docs.google.com/document/d/19jGsZxh7DX8jkAKbL1nYBa5rcByUL2EeidnYsoXfsYQ/edit#

BUG=713137
Review-Url: https://codereview.chromium.org/2963733003
Cr-Commit-Position: refs/heads/master@{#483986}
Committed: https://chromium.googlesource.com/chromium/src/+/45a1ceb8309b6076aea7d2885b7a62f8d3c549c9

[Daniel Bratell, 2017-06-28 14:19:56]

Description was changed from

==========
Scripts for unity/jumbo (default disabled) compilation.

To speed up compilation times, jumbo allows files to be compiled
together. This is a well known method to both compile faster and
create a poor man's "full program optimization". For Chromium we are
only interested in the compile times.

This patch includes the basic scripts that do the source file merging
and changes Blink Core to use those scripts. If the gn configuration
includes: use_blink_jumbo_build = true then Blink Core will use jumbo
compile. Otherwise it will compile as usual.

The expected speedup from using Jumbo on Blink Core (and nothing else)
is about 17% of the content_shell+blink_tests compilation CPU
time. This is about half an hour for people building with an ordinary
computer, but less both in percentage and minutes if using some kind
of build accelerator like goma.

BUG=713137
==========

to

==========
Scripts for unity/jumbo (default disabled) compilation.

To speed up compilation times, jumbo allows files to be compiled
together. This is a well known method ("unity builds") to both
compile faster and create a poor man's "full program optimization".
For Chromium we are only interested in the compile times.

This patch includes the basic scripts that do the source file merging
and changes Blink Core to use those scripts. If the gn configuration
includes: use_blink_jumbo_build = true then Blink Core will use jumbo
compile. Otherwise it will compile as usual.

The expected speedup from using Jumbo on Blink Core (and nothing else)
is about 17% of the content_shell+blink_tests compilation CPU
time. This is about half an hour for people building with an ordinary
computer, but less both in percentage and minutes if using some kind
of build accelerator like goma.

More information in
https://docs.google.com/document/d/19jGsZxh7DX8jkAKbL1nYBa5rcByUL2EeidnYsoXfs...

BUG=713137
==========

[Daniel Bratell, 2017-06-28 14:20:09]

The CQ bit was checked by bratell@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2017-06-28 14:20:24]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Daniel Bratell, 2017-06-28 14:30:59]

bratell@opera.com changed reviewers:
+ dpranke@chromium.org

[Daniel Bratell, 2017-06-28 14:31:00]

dpranke, this is a basic jumbo patch with it default disabled. If this lands, it
should make it possible to setup a builder that enables it for testing.

I am not sure whether jumbo.gni and jumbo.py should be in build or in
build/config or maybe be in two different places. There are other scripts and
other gni files in build so they are not out of place, but maybe there is
somewhere better for them.

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni
File build/jumbo.gni (right):

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode10
build/jumbo.gni:10: use_blink_jumbo_build = false
It is named "blink" here, but considering that the ambition is that this will be
used far outside blink, maybe "use_jumbo_build" is a better name?

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode110
build/jumbo.gni:110: if (source_ext == "h" || source_ext == "mm") {
I have plans for Objective-C eventually, but I don't want to make the system
more complex before everyone is familiar with the base functionality.

[commit-bot: I haz the power, 2017-06-28 16:24:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-28 16:24:19]

Dry run: This issue passed the CQ dry run.

[Dirk Pranke, 2017-06-29 23:09:45]

dpranke@chromium.org changed reviewers:
+ brucedawson@chromium.org

[Dirk Pranke, 2017-06-29 23:09:46]

This basically looks okay, although I still think that ultimately we'll want to
bake this functionality into GN itself, rather than forcing everyone to rewrite
all of their build files to be jumbo-aware.

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni
File build/jumbo.gni (right):

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode10
build/jumbo.gni:10: use_blink_jumbo_build = false
On 2017/06/28 14:31:00, Daniel Bratell wrote:
> It is named "blink" here, but considering that the ambition is that this will
be
> used far outside blink, maybe "use_jumbo_build" is a better name?

How opposed are you to using the 'unity' name rather than the 'jumbo' name?

I would rather use unity if that's okay, I think it's at least a bit more
understood although neither usage is common.

I would get rid of the 'blink' part either way though.

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode29
build/jumbo.gni:29: #      globally enabled.
Overloading a single flag like this seems kinda awkward. WDYT about having two
different flags: always_build_jumbo and never_build_jumbo or something like
that?

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode55
build/jumbo.gni:55: files_per_chunk = 200
Maybe we should make this configurable so we can tune it more easily, or perhaps
make this an input parameter to the template? When I was testing my version of
the jumbo build concept, I would see significant speedups on much smaller
targets, but if the chunk size was too large some targets wouldn't be
parallelized at all. Or maybe there should be a minimum number of chunks per
target, or something?

https://codereview.chromium.org/2963733003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/exported/BUILD.gn (right):

https://codereview.chromium.org/2963733003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/exported/BUILD.gn:96:
"WebSearchableFormData.cpp",  # Too many different toHTMLInputElement
(ListedElement and HTMLElement)
I don't understand this comment. I'm assuming you get some sort of namespace
collision that is too hard to clean up?

[Dirk Pranke, 2017-06-29 23:31:24]

On 2017/06/28 14:31:00, Daniel Bratell wrote:
> I am not sure whether jumbo.gni and jumbo.py should be in build or in
> build/config or maybe be in two different places. There are other scripts and
> other gni files in build so they are not out of place, but maybe there is
> somewhere better for them.

I'd probably move them to build/config.

[Daniel Bratell, 2017-06-30 08:22:20]

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni
File build/jumbo.gni (right):

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode10
build/jumbo.gni:10: use_blink_jumbo_build = false
On 2017/06/29 23:09:46, Dirk Pranke wrote:
> On 2017/06/28 14:31:00, Daniel Bratell wrote:
> > It is named "blink" here, but considering that the ambition is that this
will
> be
> > used far outside blink, maybe "use_jumbo_build" is a better name?
> 
> How opposed are you to using the 'unity' name rather than the 'jumbo' name?
> 
> I would rather use unity if that's okay, I think it's at least a bit more
> understood although neither usage is common.

I don't think it's good to call it unity because it is a word already used for
so many other things. In the current source it's used to talk about the Ubuntu
graphical environment/style and about audio filters and QUIC congestion control.
In the wider software world it is a 3D graphical engine and other things.

Using unity for this will make it harder for those people to discuss their own
code without confusion, and it will make it harder for us to talk about unity
builds without confusion. When I started talking about this I noticed that
people thought they knew what I was talking about and then tuned out. That
stopped happening when I changed to Jumbo.

I understand your argument, and I did try to call it unity initially because
that is the most accepted term for it, but it wasn't useful beyond the ~3 people
that happened to know about it in advance.

> I would get rid of the 'blink' part either way though.

Will do!

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode29
build/jumbo.gni:29: #      globally enabled.
On 2017/06/29 23:09:46, Dirk Pranke wrote:
> Overloading a single flag like this seems kinda awkward. WDYT about having two
> different flags: always_build_jumbo and never_build_jumbo or something like
> that?

Yes, renaming this one would really be useful for readability. Do you think
about those flags being two boolean values? They sound like an annotation and
I'm not sure how to do that in gn?

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode55
build/jumbo.gni:55: files_per_chunk = 200
On 2017/06/29 23:09:46, Dirk Pranke wrote:
> Maybe we should make this configurable so we can tune it more easily, or
perhaps
> make this an input parameter to the template? When I was testing my version of
> the jumbo build concept, I would see significant speedups on much smaller
> targets, but if the chunk size was too large some targets wouldn't be
> parallelized at all. Or maybe there should be a minimum number of chunks per
> target, or something?

I can make it a declare_args configurable variable with a default to make it
easier to tune, though for every different size, the sets of files grouped with
each other changes so just because 200 compiles, 199 or 201 may not. (100
probably will though since it's just halving).

https://codereview.chromium.org/2963733003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/exported/BUILD.gn (right):

https://codereview.chromium.org/2963733003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/exported/BUILD.gn:96:
"WebSearchableFormData.cpp",  # Too many different toHTMLInputElement
(ListedElement and HTMLElement)
On 2017/06/29 23:09:46, Dirk Pranke wrote:
> I don't understand this comment. I'm assuming you get some sort of namespace
> collision that is too hard to clean up?

Yes, HTMLObjectElement inherits from both ListedElement and HTMLElement. There
are different global templates with the name toHTMLInputElement that can handle
either type, and if both those sets of templates are visible at the same time,
the compiler doesn't know which template to expand.

The patch to rename/restructure it is too big to land without having a concrete
reason so I haven't even tried. Once this is in the tree I plan to change the
code so none of these exclusions are needed but I have a "chicken or egg"
problem.

[Daniel Bratell, 2017-06-30 08:44:20]

On 2017/06/29 23:09:46, Dirk Pranke wrote:
> This basically looks okay, although I still think that ultimately we'll want
to
> bake this functionality into GN itself, rather than forcing everyone to
rewrite
> all of their build files to be jumbo-aware.

Yes, it would be a nice gn feature, but I don't think we'll get away from having
signals in the .gn files. Grouped files will not always work right away so you
always need to be able to tune or toggle the feature on a "by target" basis.

Now many of Chromium targets use shared templates so you can get away, as in
this patch, with a 2-3 line change in a template instead of 2 lines in every
target. My chromium tree seems to have 344 non-phony targets so changing all
that matter is at least possible (and compared to some projects, even trivial).

[Daniel Bratell, 2017-06-30 10:09:53]

Please take a new look. Fixed the things you mentioned I think.

The patch still calls things jumbo primarily but only because "unity" or "unity
build system" have so many drawbacks. I can't see a perfect solution here. :-/

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni
File build/jumbo.gni (right):

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode29
build/jumbo.gni:29: #      globally enabled.
On 2017/06/29 23:09:46, Dirk Pranke wrote:
> Overloading a single flag like this seems kinda awkward. WDYT about having two
> different flags: always_build_jumbo and never_build_jumbo or something like
> that?

Done.

https://codereview.chromium.org/2963733003/diff/1/build/jumbo.gni#newcode55
build/jumbo.gni:55: files_per_chunk = 200
On 2017/06/29 23:09:46, Dirk Pranke wrote:
> Maybe we should make this configurable so we can tune it more easily, or
perhaps
> make this an input parameter to the template? When I was testing my version of
> the jumbo build concept, I would see significant speedups on much smaller
> targets, but if the chunk size was too large some targets wouldn't be
> parallelized at all. Or maybe there should be a minimum number of chunks per
> target, or something?

Done.

https://codereview.chromium.org/2963733003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/exported/BUILD.gn (right):

https://codereview.chromium.org/2963733003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/exported/BUILD.gn:96:
"WebSearchableFormData.cpp",  # Too many different toHTMLInputElement
(ListedElement and HTMLElement)
On 2017/06/30 08:22:19, Daniel Bratell wrote:
> On 2017/06/29 23:09:46, Dirk Pranke wrote:
> > I don't understand this comment. I'm assuming you get some sort of namespace
> > collision that is too hard to clean up?
> 
> Yes, HTMLObjectElement inherits from both ListedElement and HTMLElement. There
> are different global templates with the name toHTMLInputElement that can
handle
> either type, and if both those sets of templates are visible at the same time,
> the compiler doesn't know which template to expand.
> 
> The patch to rename/restructure it is too big to land without having a
concrete
> reason so I haven't even tried. Once this is in the tree I plan to change the
> code so none of these exclusions are needed but I have a "chicken or egg"
> problem.

Documented it in https://bugs.chromium.org/p/chromium/issues/detail?id=738389

[Daniel Bratell, 2017-06-30 11:49:53]

The CQ bit was checked by bratell@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2017-06-30 11:50:02]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-30 13:41:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-30 13:41:09]

Dry run: This issue passed the CQ dry run.

[brucedawson, 2017-06-30 18:49:15]

Thanks for doing this work. lgtm if dpranke@ is satisfied (I just did a quick
look).

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni
File build/config/jumbo.gni (right):

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:24: # less wall clock when compiling with 4 cores.
I would expect that we would want to tune this for eight-core or twelve-core
machines rather than four-core. But, I don't want to block this CL on that issue
because I know it takes a lot of testing to measure different values.

[Dirk Pranke, 2017-06-30 21:38:46]

This basically lgtm, though I have lots of nits :).

I guess I can live with the "jumbo" name; you're right that "unity" will cause
confusion w/ the game engine.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni
File build/config/jumbo.gni (right):

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:9: # compilation.
We should document in more details somewhere what we mean by a "jumbo build" /
"files compiled together". I think the right thing to do would probably be to
link to an in-repo markdown page that talks about what this is, why we do it,
how to use this stuff, and common gotchas. I don't think we need to block this
CL on that page being written, though; we could add this in a follow-up.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:24: # less wall clock when compiling with 4 cores.
On 2017/06/30 18:49:15, brucedawson wrote:
> I would expect that we would want to tune this for eight-core or twelve-core
> machines rather than four-core. But, I don't want to block this CL on that
issue
> because I know it takes a lot of testing to measure different values.

I feel similarly :). 200 is fine for now.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:35: #      "static_library".
Given the set_defaults() call on line 138, this means that this currently only
works for static_libraries and source_sets (and things like the component
template that reduce to that)? We should probably add an assert for that, or at
least add asserts that they're *not* passing in target_types that are known not
to work.

I'd like to eventually make this work for executables, shared_libraries, and the
other types of targets, but I think you probably would have to change the
approach a bit, maybe to define a possibly_jumbo version of each target type or
something (this is also part of the reason why I think this ultimately should be
built into GN).

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:39: #      globally disabled. Otherwise it has no effect
Nit: add periods after "no effect", here and on line 43.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:47: #      the rest. Can be used if files are
problematic.
s/Can be used if files are problematic/This can be necessary if merging the
files causes compilation issues and fixing the issues is impractical./

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:89: action(target_name + "_jumbo") {
I'd pull target_name + "_jumbo" into a variable so that you can reuse it here
and on line 119. I might also call it "__jumbo_merge" or
"__merge_for_jumbo_build" or something like that. We usually use two underscores
for helper targets in templates, and I don't think being particularly verbose is
too awful here.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:95: [ "--file-list={{response_file_name}}" ]
I think you need to set inputs = invoker.sources - excluded_sources here, to
know when we need to re-merge?

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.py
File build/config/jumbo.py (right):

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.py#n...
build/config/jumbo.py:1: #!/usr/bin/env python
I worry a bit that "jumbo.py" might be too opaque of a name. Maybe
"merge_for_jumbo_build.py" or something like that?

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.py#n...
build/config/jumbo.py:47: if filename.endswith((".h", ".mm")):
Can you add a comment here about why we're skipping over the .h/.mm files (in
addition to the comment you have in the .gni file)?

[Daniel Bratell, 2017-07-03 09:21:17]

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni
File build/config/jumbo.gni (right):

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:9: # compilation.
On 2017/06/30 21:38:46, Dirk Pranke wrote:
> We should document in more details somewhere what we mean by a "jumbo build" /
> "files compiled together". I think the right thing to do would probably be to
> link to an in-repo markdown page that talks about what this is, why we do it,
> how to use this stuff, and common gotchas. I don't think we need to block this
> CL on that page being written, though; we could add this in a follow-up.

I will move some text from the current Google Doc to a markdown document in
another CL.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:24: # less wall clock when compiling with 4 cores.
On 2017/06/30 21:38:46, Dirk Pranke wrote:
> On 2017/06/30 18:49:15, brucedawson wrote:
> > I would expect that we would want to tune this for eight-core or twelve-core
> > machines rather than four-core. But, I don't want to block this CL on that
> issue
> > because I know it takes a lot of testing to measure different values.
> 
> I feel similarly :). 200 is fine for now.

Looking forward to numbers from other computers. 4 cores is still the highest
number of cores on consumer processors. One good thing with high numbers is that
you can divide them down so if 200 works, 100, 50 and 25 probably compile as
well. 400 on the other hand may not.

I ran some experiments with 100 and I think 100 might be close enough to 200
that we could shift down to 100 with only 5-10 minutes longer full builds, but
I'm leaving the final tuning for post-landing.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:35: #      "static_library".
On 2017/06/30 21:38:46, Dirk Pranke wrote:
> Given the set_defaults() call on line 138, this means that this currently only
> works for static_libraries and source_sets (and things like the component
> template that reduce to that)? We should probably add an assert for that, or
at
> least add asserts that they're *not* passing in target_types that are known
not
> to work.
> 
> I'd like to eventually make this work for executables, shared_libraries, and
the
> other types of targets, but I think you probably would have to change the
> approach a bit, maybe to define a possibly_jumbo version of each target type
or
> something (this is also part of the reason why I think this ultimately should
be
> built into GN).
> 

I have considered making one jumbo_source_set, one jumbo_static_library, one
jumbo_component, one jumbo_split_static_library and so on but since it would
make jumbo.gni a bit more verbose so I delayed it until later. Right now it
seems to work for everything I've tried, but I might not have tried executables.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:39: #      globally disabled. Otherwise it has no effect
On 2017/06/30 21:38:46, Dirk Pranke wrote:
> Nit: add periods after "no effect", here and on line 43.

Done.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:47: #      the rest. Can be used if files are
problematic.
On 2017/06/30 21:38:45, Dirk Pranke wrote:
> s/Can be used if files are problematic/This can be necessary if merging the
> files causes compilation issues and fixing the issues is impractical./

Done.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:89: action(target_name + "_jumbo") {
On 2017/06/30 21:38:45, Dirk Pranke wrote:
> I'd pull target_name + "_jumbo" into a variable so that you can reuse it here
> and on line 119. I might also call it "__jumbo_merge" or
> "__merge_for_jumbo_build" or something like that. We usually use two
underscores
> for helper targets in templates, and I don't think being particularly verbose
is
> too awful here.

Done.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.gni#...
build/config/jumbo.gni:95: [ "--file-list={{response_file_name}}" ]
On 2017/06/30 21:38:46, Dirk Pranke wrote:
> I think you need to set inputs = invoker.sources - excluded_sources here, to
> know when we need to re-merge?

Not for the #include method since the contents of the files actually doesn't
matter. It would be needed if the files were physically merged into large files.
That is slower and more complicated but has a few benefits so we might end up
there eventually. For now I'm choosing the least complicated method until we
know that we need something more complicated.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.py
File build/config/jumbo.py (right):

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.py#n...
build/config/jumbo.py:1: #!/usr/bin/env python
On 2017/06/30 21:38:46, Dirk Pranke wrote:
> I worry a bit that "jumbo.py" might be too opaque of a name. Maybe
> "merge_for_jumbo_build.py" or something like that?

Done.

https://codereview.chromium.org/2963733003/diff/20001/build/config/jumbo.py#n...
build/config/jumbo.py:47: if filename.endswith((".h", ".mm")):
On 2017/06/30 21:38:46, Dirk Pranke wrote:
> Can you add a comment here about why we're skipping over the .h/.mm files (in
> addition to the comment you have in the .gni file)?

Done.

Note: The code will change completely when I add Objective-C and C support here
(another CL which I haven't uploaded yet).

[Daniel Bratell, 2017-07-03 09:21:35]

The CQ bit was checked by bratell@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2017-07-03 09:21:44]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Daniel Bratell, 2017-07-03 09:22:34]

Description was changed from

==========
Scripts for unity/jumbo (default disabled) compilation.

To speed up compilation times, jumbo allows files to be compiled
together. This is a well known method ("unity builds") to both
compile faster and create a poor man's "full program optimization".
For Chromium we are only interested in the compile times.

This patch includes the basic scripts that do the source file merging
and changes Blink Core to use those scripts. If the gn configuration
includes: use_blink_jumbo_build = true then Blink Core will use jumbo
compile. Otherwise it will compile as usual.

The expected speedup from using Jumbo on Blink Core (and nothing else)
is about 17% of the content_shell+blink_tests compilation CPU
time. This is about half an hour for people building with an ordinary
computer, but less both in percentage and minutes if using some kind
of build accelerator like goma.

More information in
https://docs.google.com/document/d/19jGsZxh7DX8jkAKbL1nYBa5rcByUL2EeidnYsoXfs...

BUG=713137
==========

to

==========
Scripts for unity/jumbo (default disabled) compilation.

To speed up compilation times, jumbo allows files to be compiled
together. This is a well known method ("unity builds") to both
compile faster and create a poor man's "full program optimization".
For Chromium we are only interested in the compile times.

This patch includes the basic scripts that do the source file merging
and changes Blink Core to use those scripts. If the gn configuration
includes: use_jumbo_build = true then Blink Core will use jumbo
compile. Otherwise it will compile as usual.

The expected speedup from using Jumbo on Blink Core (and nothing else)
is about 17% of the content_shell+blink_tests compilation CPU
time. This is about half an hour for people building with an ordinary
computer, but less both in percentage and minutes if using some kind
of build accelerator like goma.

More information in
https://docs.google.com/document/d/19jGsZxh7DX8jkAKbL1nYBa5rcByUL2EeidnYsoXfs...

BUG=713137
==========

[Daniel Bratell, 2017-07-03 10:08:15]

The CQ bit was unchecked by bratell@opera.com

[Daniel Bratell, 2017-07-03 10:08:19]

The CQ bit was checked by bratell@opera.com

[Daniel Bratell, 2017-07-03 10:08:19]

The patchset sent to the CQ was uploaded after l-g-t-m from
dpranke@chromium.org, brucedawson@chromium.org
Link to the patchset: https://codereview.chromium.org/2963733003/#ps40001
(title: "Addressed review issues.")

[commit-bot: I haz the power, 2017-07-03 10:08:34]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-03 11:14:39]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1499076499105020,
"parent_rev": "c81b9ab9c23121da0539e13ab3b6fca9b08b37c8", "commit_rev":
"45a1ceb8309b6076aea7d2885b7a62f8d3c549c9"}

[commit-bot: I haz the power, 2017-07-03 11:14:53]

Description was changed from

==========
Scripts for unity/jumbo (default disabled) compilation.

To speed up compilation times, jumbo allows files to be compiled
together. This is a well known method ("unity builds") to both
compile faster and create a poor man's "full program optimization".
For Chromium we are only interested in the compile times.

This patch includes the basic scripts that do the source file merging
and changes Blink Core to use those scripts. If the gn configuration
includes: use_jumbo_build = true then Blink Core will use jumbo
compile. Otherwise it will compile as usual.

The expected speedup from using Jumbo on Blink Core (and nothing else)
is about 17% of the content_shell+blink_tests compilation CPU
time. This is about half an hour for people building with an ordinary
computer, but less both in percentage and minutes if using some kind
of build accelerator like goma.

More information in
https://docs.google.com/document/d/19jGsZxh7DX8jkAKbL1nYBa5rcByUL2EeidnYsoXfs...

BUG=713137
==========

to

==========
Scripts for unity/jumbo (default disabled) compilation.

To speed up compilation times, jumbo allows files to be compiled
together. This is a well known method ("unity builds") to both
compile faster and create a poor man's "full program optimization".
For Chromium we are only interested in the compile times.

This patch includes the basic scripts that do the source file merging
and changes Blink Core to use those scripts. If the gn configuration
includes: use_jumbo_build = true then Blink Core will use jumbo
compile. Otherwise it will compile as usual.

The expected speedup from using Jumbo on Blink Core (and nothing else)
is about 17% of the content_shell+blink_tests compilation CPU
time. This is about half an hour for people building with an ordinary
computer, but less both in percentage and minutes if using some kind
of build accelerator like goma.

More information in
https://docs.google.com/document/d/19jGsZxh7DX8jkAKbL1nYBa5rcByUL2EeidnYsoXfs...

BUG=713137

Review-Url: https://codereview.chromium.org/2963733003
Cr-Commit-Position: refs/heads/master@{#483986}
Committed:
https://chromium.googlesource.com/chromium/src/+/45a1ceb8309b6076aea7d2885b7a...
==========

[commit-bot: I haz the power, 2017-07-03 11:14:54]

Committed patchset #3 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/45a1ceb8309b6076aea7d2885b7a...