Optimize yasm even in debug builds

Optimize yasm even in debug builds

Running yasm on highbd_sad4d_sse2.asm takes about ~33 seconds on debug
component builds on Windows - closer to 42 seconds when the system is
under load. This is partially because compiler optimizations are
disabled in debug builds (costs ~5 seconds) and partially because we
link with the debug CRT (costs ~15 seconds). This change makes it so
that we always enable optimizations and always link with the release
CRT, thus reducing the time to run yasm on highbd_sad4d_sse2.asm from
~33 seconds to ~13 seconds.

Further improvements could be obtained by only running yasm once on the
.asm files, but such a change is left for later.

The total CPU-time savings is tiny compared to the cost of a full build,
but on some goma builds this step ends up being the long pole which
serializes the build and costs an estimated 5% of elapsed build time.

BUG=722617
Review-Url: https://codereview.chromium.org/2885213002
Cr-Commit-Position: refs/heads/master@{#473066}
Committed: https://chromium.googlesource.com/chromium/src/+/9c90eb122f3327c8c03bbf2171a97cb157f89459

[brucedawson, 2017-05-16 21:05:45]

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

[commit-bot: I haz the power, 2017-05-16 21:06:45]

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-05-16 23:11:51]

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

[commit-bot: I haz the power, 2017-05-16 23:11:51]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[brucedawson, 2017-05-16 23:25:26]

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

[commit-bot: I haz the power, 2017-05-16 23:26:20]

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-05-17 03:27:47]

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

[commit-bot: I haz the power, 2017-05-17 03:27:48]

Dry run: This issue passed the CQ dry run.

[brucedawson, 2017-05-17 16:45:17]

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

[brucedawson, 2017-05-17 16:45:18]

Any thoughts on this fix? This may nicely improve the speed of some debug
builds.

I tried using a shared config to make the settings changes instead of
replicating them to three different build targets but it appears that you can't
use a config to *subtract* configs - is there any alternative for reuse?

[brucedawson, 2017-05-18 21:11:22]

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

[commit-bot: I haz the power, 2017-05-18 21:12:30]

Dry run: CQ is trying da patch.

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

[brettw, 2017-05-18 21:25:10]

lgtm

[brucedawson, 2017-05-18 21:29:15]

Description was changed from

==========
Optimize yasm even in debug builds

Running yasm on highbd_sad4d_sse2.asm takes about ~33 seconds on debug
component builds on Windows - closer to 42 seconds when the system is
under load. This is partially because compiler optimizations are
disabled in debug builds (costs ~5 seconds) and partially because we
link with the debug CRT (costs ~15 seconds). This change makes it so
that we always enable optimizations and always link with the release
CRT, thus reducing the time to run yasm on highbd_sad4d_sse2.asm from
~33 seconds to ~13 seconds.

Further improvements could be obtained by only running yasm once on the
.asm files, but such a change is left for later.

The total CPU-time savings is tiny compared to the cost of a full build,
but on some goma builds this step ends up being the long pole which
serializes the build and costs an estimated 5% of elapsed build time.

BUG=722617
==========

to

==========
Optimize yasm even in debug builds

Running yasm on highbd_sad4d_sse2.asm takes about ~33 seconds on debug
component builds on Windows - closer to 42 seconds when the system is
under load. This is partially because compiler optimizations are
disabled in debug builds (costs ~5 seconds) and partially because we
link with the debug CRT (costs ~15 seconds). This change makes it so
that we always enable optimizations and always link with the release
CRT, thus reducing the time to run yasm on highbd_sad4d_sse2.asm from
~33 seconds to ~13 seconds.

Further improvements could be obtained by only running yasm once on the
.asm files, but such a change is left for later.

The total CPU-time savings is tiny compared to the cost of a full build,
but on some goma builds this step ends up being the long pole which
serializes the build and costs an estimated 5% of elapsed build time.

BUG=722617
==========

[brucedawson, 2017-05-18 21:29:15]

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

[DaleCurtis, 2017-05-18 22:37:47]

lgtm, maybe we should just stick binaries in Google storage like we do for
clang. Don't think there's any benefit to having this in tree otherwise.

[brucedawson, 2017-05-19 02:00:07]

The CQ bit was unchecked by brucedawson@chromium.org

[brucedawson, 2017-05-19 02:00:18]

The CQ bit was checked by brucedawson@chromium.org

[commit-bot: I haz the power, 2017-05-19 02:01:02]

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-05-19 03:45:33]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1495159218624400,
"parent_rev": "0e9353d37e60a871304084a1b34222062c4803e9", "commit_rev":
"9c90eb122f3327c8c03bbf2171a97cb157f89459"}

[commit-bot: I haz the power, 2017-05-19 03:45:47]

Description was changed from

==========
Optimize yasm even in debug builds

Running yasm on highbd_sad4d_sse2.asm takes about ~33 seconds on debug
component builds on Windows - closer to 42 seconds when the system is
under load. This is partially because compiler optimizations are
disabled in debug builds (costs ~5 seconds) and partially because we
link with the debug CRT (costs ~15 seconds). This change makes it so
that we always enable optimizations and always link with the release
CRT, thus reducing the time to run yasm on highbd_sad4d_sse2.asm from
~33 seconds to ~13 seconds.

Further improvements could be obtained by only running yasm once on the
.asm files, but such a change is left for later.

The total CPU-time savings is tiny compared to the cost of a full build,
but on some goma builds this step ends up being the long pole which
serializes the build and costs an estimated 5% of elapsed build time.

BUG=722617
==========

to

==========
Optimize yasm even in debug builds

Running yasm on highbd_sad4d_sse2.asm takes about ~33 seconds on debug
component builds on Windows - closer to 42 seconds when the system is
under load. This is partially because compiler optimizations are
disabled in debug builds (costs ~5 seconds) and partially because we
link with the debug CRT (costs ~15 seconds). This change makes it so
that we always enable optimizations and always link with the release
CRT, thus reducing the time to run yasm on highbd_sad4d_sse2.asm from
~33 seconds to ~13 seconds.

Further improvements could be obtained by only running yasm once on the
.asm files, but such a change is left for later.

The total CPU-time savings is tiny compared to the cost of a full build,
but on some goma builds this step ends up being the long pole which
serializes the build and costs an estimated 5% of elapsed build time.

BUG=722617

Review-Url: https://codereview.chromium.org/2885213002
Cr-Commit-Position: refs/heads/master@{#473066}
Committed:
https://chromium.googlesource.com/chromium/src/+/9c90eb122f3327c8c03bbf2171a9...
==========

[commit-bot: I haz the power, 2017-05-19 03:45:48]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/9c90eb122f3327c8c03bbf2171a9...