Enable incremental linking for blink_core, 32-bit

Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large and enabling
incremental linking doesn't cause build failures but doesn't help,
and probably slows down the build (due to creating the huge .ilk
file).

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit. The .ilk file
for blink_core.dll is dangerously close to the old limit, but nowhere
near the new limit.

BUG=560475
Committed: https://crrev.com/f786d3a73671671237e8ab61d0d97d85a8db7d3c
Cr-Commit-Position: refs/heads/master@{#417852}

[brucedawson, 2016-09-09 19:53:20]

The CQ bit was checked by brucedawson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-09 19:54:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[brucedawson, 2016-09-09 19:55:47]

Description was changed from

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

On 64-bit builds the .ilk file is still too large.

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit.

BUG=560475
==========

to

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large.

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit.

BUG=560475
==========

[brucedawson, 2016-09-09 21:18:24]

Description was changed from

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large.

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit.

BUG=560475
==========

to

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large and enabling
incremental linking doesn't cause build failures but doesn't help,
and probably slows down the build (due to creating the huge .ilk
file).

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit. The .ilk file
for blink_core.dll is dangerously close to the old limit, but nowhere
near the old limit.

BUG=560475
==========

[brucedawson, 2016-09-09 21:20:32]

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

[brucedawson, 2016-09-09 21:20:33]

40x faster incremental builds of blink_core! (some restrictions may apply,
32-bit only, probably requires VS 2015 Update 3).

[scottmg, 2016-09-09 21:28:45]

lgtm

It's too bad to hear that x64 is that much larger. We'd better get on that
request for an int64 instead of just a uint32 I guess. :/

[commit-bot: I haz the power, 2016-09-09 22:18:51]

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

[commit-bot: I haz the power, 2016-09-09 22:18:52]

Dry run: This issue passed the CQ dry run.

[brucedawson, 2016-09-09 22:26:28]

The CQ bit was checked by brucedawson@chromium.org

[commit-bot: I haz the power, 2016-09-09 22:27:05]

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, 2016-09-09 22:33:52]

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

[commit-bot: I haz the power, 2016-09-09 22:33:53]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[brucedawson, 2016-09-09 22:35:52]

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

[brucedawson, 2016-09-09 22:35:53]

Dirk, PTAL.

[Dirk Pranke, 2016-09-10 16:18:51]

Description was changed from

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large and enabling
incremental linking doesn't cause build failures but doesn't help,
and probably slows down the build (due to creating the huge .ilk
file).

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit. The .ilk file
for blink_core.dll is dangerously close to the old limit, but nowhere
near the old limit.

BUG=560475
==========

to

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large and enabling
incremental linking doesn't cause build failures but doesn't help,
and probably slows down the build (due to creating the huge .ilk
file).

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit. The .ilk file
for blink_core.dll is dangerously close to the old limit, but nowhere
near the new limit.

BUG=560475
==========

[Dirk Pranke, 2016-09-10 16:19:35]

lgtm

[brucedawson, 2016-09-11 00:19:43]

The CQ bit was checked by brucedawson@chromium.org

[commit-bot: I haz the power, 2016-09-11 00:19:48]

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, 2016-09-11 01:50:03]

Description was changed from

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large and enabling
incremental linking doesn't cause build failures but doesn't help,
and probably slows down the build (due to creating the huge .ilk
file).

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit. The .ilk file
for blink_core.dll is dangerously close to the old limit, but nowhere
near the new limit.

BUG=560475
==========

to

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large and enabling
incremental linking doesn't cause build failures but doesn't help,
and probably slows down the build (due to creating the huge .ilk
file).

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit. The .ilk file
for blink_core.dll is dangerously close to the old limit, but nowhere
near the new limit.

BUG=560475
==========

[commit-bot: I haz the power, 2016-09-11 01:50:04]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-11 01:52:44]

Description was changed from

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large and enabling
incremental linking doesn't cause build failures but doesn't help,
and probably slows down the build (due to creating the huge .ilk
file).

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit. The .ilk file
for blink_core.dll is dangerously close to the old limit, but nowhere
near the new limit.

BUG=560475
==========

to

==========
Enable incremental linking for blink_core, 32-bit

Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:

> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome

from ~400 s to ~10 s. Which is faster.

Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.

On 64-bit builds the .ilk file is still too large and enabling
incremental linking doesn't cause build failures but doesn't help,
and probably slows down the build (due to creating the huge .ilk
file).

This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit. The .ilk file
for blink_core.dll is dangerously close to the old limit, but nowhere
near the new limit.

BUG=560475

Committed: https://crrev.com/f786d3a73671671237e8ab61d0d97d85a8db7d3c
Cr-Commit-Position: refs/heads/master@{#417852}
==========

[commit-bot: I haz the power, 2016-09-11 01:52:45]

Patchset 1 (id:??) landed as
https://crrev.com/f786d3a73671671237e8ab61d0d97d85a8db7d3c
Cr-Commit-Position: refs/heads/master@{#417852}

[gab, 2017-04-26 18:41:29]

On 2016/09/11 01:52:45, commit-bot: I haz the power wrote:
> Patchset 1 (id:??) landed as
> https://crrev.com/f786d3a73671671237e8ab61d0d97d85a8db7d3c
> Cr-Commit-Position: refs/heads/master@{#417852}