Reduce DefaultConcurrentLinks from phys/4GB to phys/5GB.

Reduce DefaultConcurrentLinks from phys/4GB to phys/5GB.

VS 2015 uses about 20% more memory when linking. This caused a
severe page-fault storm on my development machine and subsequent tests
showed that linking could use ~63 GB of RAM (15 parallel links on a
64 GB machine). This suggests that VS 2013 would also be using a lot
of RAM (52.5 GB?) such that very little was left for other
applications or disk cache.

Linker working sets vary wildly but for some they can be very high:
unit_tests.exe hits peak working sets of 7.8 GB/9.5 GB on VS
2013/2015.

This change reduces parallel links by 20% (increase RAM-per-linker by
25%). The value can be overridden by setting GYP_LINK_CONCURRENCY.

BUG=440500
R=thakis@chromium.org

Committed: https://chromium.googlesource.com/external/gyp/+/6ee91ad8659871916f9aa840d42e1513befdf638

[brucedawson, 2015-07-28 00:02:42]

What do you think of doing this?

I could run some tests to see if it affects build time noticeably (on VS 2013 or
VS 2015) but I'm not sure if that will tell us much given build-time noisiness
and the variety of build configurations (at the very least
buildtype=Official/normal/component).

I suspect that this will help in some cases (more disk cache) and hurt in others
(less parallelism).

Note that GetDefaultConcurrentLinks exists in three places - the other is in
build\toolchain\get_concurrent_links.py in two locations. I'd fix those as well.

[brucedawson, 2015-07-28 17:43:44]

I ran some overnight tests with varying levels of GYP_LINK_CONCURRENCY.
In all cases I built all of Chrome (no target specified), release
builds, non-component, non-official, three runs with each configuration.
These tests were run with VS 2013 on a Z620 with all other programs
closed.

The builds with GYP_LINK_CONCURRENCY set to 10 and 12 ran about
30 seconds (~1%) faster than the builds with GYP_LINK_CONCURRENCY set
to 15.

The slightly improved speed is probably from having more RAM available
for the disk cache. On a machine with other programs consuming memory
I would expect the speedup from having fewer parallel links to be slightly
greater.

The results for component builds or for just having 'chrome' as a target
might be different, but the initial results do support making this change.

[Nico, 2015-07-28 17:46:34]

lgtm

[Nico, 2015-07-28 18:19:40]

Committed patchset #1 (id:1) manually as
6ee91ad8659871916f9aa840d42e1513befdf638 (presubmit successful).

[Nico, 2015-07-28 18:20:07]

Right, I think gyp has a separate committers list, sorry. I landed this for you.