Avoid some static initializers in Windows builds

Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll | find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Once we switch to VC++ 2017 we will be able to use
constexpr in more places.

The static keyword was removed in a few places because it is redundant
to const/constexpr.

The effect on non-VC++ builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2942273002
Cr-Commit-Position: refs/heads/master@{#480928}
Committed: https://chromium.googlesource.com/chromium/src/+/3aa1f0e28252bef52ab1869730efc2938185c3cc

[brucedawson, 2017-06-16 17:17:55]

Description was changed from

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eleven
static initializers and has the following effect on binary size:

Memory size change from master\chrome_child.dll to constexpr_4\chrome_child.dll
       .text:   -5504 bytes change
      .rdata:    5328 bytes change
       .data:   -5632 bytes change
      .reloc:   -1224 bytes change
Total change:   -7032 bytes

Results on the official builds will be slightly different, but most of
these static initializers were originally detected in official builds.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
==========

to

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eleven
static initializers and has the following effect on binary size:

Memory size change from master\chrome_child.dll to constexpr_4\chrome_child.dll
       .text:   -5504 bytes change
      .rdata:    5328 bytes change
       .data:   -5632 bytes change
      .reloc:   -1224 bytes change
Total change:   -7032 bytes

Results on the official builds will be slightly different, but most of
these static initializers were originally detected in official builds.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[brucedawson, 2017-06-16 17:17:57]

Description was changed from

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eleven
static initializers and has the following effect on binary size:

Memory size change from master\chrome_child.dll to constexpr_4\chrome_child.dll
       .text:   -5504 bytes change
      .rdata:    5328 bytes change
       .data:   -5632 bytes change
      .reloc:   -1224 bytes change
Total change:   -7032 bytes

Results on the official builds will be slightly different, but most of
these static initializers were originally detected in official builds.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eleven
static initializers and has the following effect on binary size:

Memory size change from master\chrome_child.dll to constexpr_4\chrome_child.dll
       .text:   -5504 bytes change
      .rdata:    5328 bytes change
       .data:   -5632 bytes change
      .reloc:   -1224 bytes change
Total change:   -7032 bytes

Results on the official builds will be slightly different, but most of
these static initializers were originally detected in official builds.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[brucedawson, 2017-06-16 17:18:15]

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

[commit-bot: I haz the power, 2017-06-16 17:18:32]

Dry run: CQ is trying da patch.

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

[brucedawson, 2017-06-16 17:24:24]

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

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

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-16 17:58:33]

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

[commit-bot: I haz the power, 2017-06-16 17:58:34]

Dry run: Try jobs failed on following builders:
  linux_layout_tests_slimming_paint_v2 on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_layout_te...)

[brucedawson, 2017-06-16 18:10:28]

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

[commit-bot: I haz the power, 2017-06-16 18:10:50]

Dry run: CQ is trying da patch.

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

[brucedawson, 2017-06-16 18:13:03]

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

[commit-bot: I haz the power, 2017-06-16 18:13:08]

Dry run: CQ is trying da patch.

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

[brucedawson, 2017-06-16 18:29:40]

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

[commit-bot: I haz the power, 2017-06-16 18:29:58]

Dry run: CQ is trying da patch.

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

[brucedawson, 2017-06-16 18:44:47]

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

[commit-bot: I haz the power, 2017-06-16 18:45:14]

Dry run: CQ is trying da patch.

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

[brucedawson, 2017-06-16 19:31:46]

Description was changed from

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eleven
static initializers and has the following effect on binary size:

Memory size change from master\chrome_child.dll to constexpr_4\chrome_child.dll
       .text:   -5504 bytes change
      .rdata:    5328 bytes change
       .data:   -5632 bytes change
      .reloc:   -1224 bytes change
Total change:   -7032 bytes

Results on the official builds will be slightly different, but most of
these static initializers were originally detected in official builds.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. It would avoid eleven and save some binary size if
we were using VC++ 2017.

Results on the official builds will be slightly different, but most of
these static initializers were originally detected in official builds.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[brucedawson, 2017-06-16 19:33:15]

Description was changed from

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. It would avoid eleven and save some binary size if
we were using VC++ 2017.

Results on the official builds will be slightly different, but most of
these static initializers were originally detected in official builds.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Savings can be better once we switch to VC++ 2017
and can use constexpr in more places.

Results on the official builds will be slightly different, but most of
these static initializers were originally detected in official builds.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[brucedawson, 2017-06-16 19:38:27]

brucedawson@chromium.org changed reviewers:
+ jochen@chromium.org, tkent@chromium.org

[brucedawson, 2017-06-16 19:39:33]

Description was changed from

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Savings can be better once we switch to VC++ 2017
and can use constexpr in more places.

Results on the official builds will be slightly different, but most of
these static initializers were originally detected in official builds.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Savings can be better once we switch to VC++ 2017
and can use constexpr in more places.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[commit-bot: I haz the power, 2017-06-16 19:46:09]

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

[commit-bot: I haz the power, 2017-06-16 19:46:10]

Dry run: Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[brucedawson, 2017-06-16 20:09:49]

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

[commit-bot: I haz the power, 2017-06-16 20:10:06]

Dry run: CQ is trying da patch.

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

[brucedawson, 2017-06-16 20:26:58]

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

[commit-bot: I haz the power, 2017-06-16 20:27:20]

Dry run: CQ is trying da patch.

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

[brucedawson, 2017-06-16 20:51:21]

Description was changed from

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Savings can be better once we switch to VC++ 2017
and can use constexpr in more places.

Not bad for just replacing const with constexpr. The static keyword was
removed in a few places because it is redundant to const/constexpr.

The effect on non-Windows builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Savings can be better once we switch to VC++ 2017
and can use constexpr in more places.

The static keyword was removed in a few places because it is redundant
to const/constexpr.

The effect on non-VC++ builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[brucedawson, 2017-06-16 22:08:51]

Description was changed from

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Savings can be better once we switch to VC++ 2017
and can use constexpr in more places.

The static keyword was removed in a few places because it is redundant
to const/constexpr.

The effect on non-VC++ builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Once we switch to VC++ 2017 we will be able to use
constexpr in more places.

The static keyword was removed in a few places because it is redundant
to const/constexpr.

The effect on non-VC++ builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[brucedawson, 2017-06-16 22:11:47]

brucedawson@chromium.org changed reviewers:
- jochen@chromium.org

[brucedawson, 2017-06-16 22:13:55]

Simple change - PTAL.

[commit-bot: I haz the power, 2017-06-16 22:30:50]

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

[commit-bot: I haz the power, 2017-06-16 22:30:51]

Dry run: This issue passed the CQ dry run.

[tkent, 2017-06-18 23:29:20]

third_party/WebKit lgtm

[brucedawson, 2017-06-19 23:04:48]

brucedawson@chromium.org changed reviewers:
+ gab@chromium.org, tdresser@chromium.org

[brucedawson, 2017-06-19 23:04:49]

gab@ can you look at chrome\install_static?
tdressers can you look at content\renderer\input?

Trivial change.

Thanks.

[grt (UTC plus 2), 2017-06-20 06:49:14]

grt@chromium.org changed reviewers:
+ grt@chromium.org

[grt (UTC plus 2), 2017-06-20 06:49:15]

install_static lgtm

[dtapuska, 2017-06-20 14:49:28]

On 2017/06/20 06:49:15, grt (UTC plus 2) wrote:
> install_static lgtm

input/* lgtm (tdresser is OOO)

[brucedawson, 2017-06-20 17:28:23]

The CQ bit was checked by brucedawson@chromium.org

[commit-bot: I haz the power, 2017-06-20 17:28:39]

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-20 20:17:04]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1497979703932910,
"parent_rev": "9ebd37eb06f548f94cab9719b07ad4615b4725cd", "commit_rev":
"3aa1f0e28252bef52ab1869730efc2938185c3cc"}

[commit-bot: I haz the power, 2017-06-20 20:17:19]

Description was changed from

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Once we switch to VC++ 2017 we will be able to use
constexpr in more places.

The static keyword was removed in a few places because it is redundant
to const/constexpr.

The effect on non-VC++ builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Avoid some static initializers in Windows builds

Running the static_initializers tool on the canary build of
chrome_child.dll showed a few dozen static initializers. It was run like
this:

    > tools\win\static_initializers\static_initializers.exe chrome_child.dll |
find "obj/" | find "initializer"

Many of these are trivially avoidable by tagging the objects in question
as constexpr. This saves some startup cost, some code size, and it
avoids creating so many private pages in the data segment. Testing with
a non-official 32-bit release build shows that this change avoids eight
static initializers. Once we switch to VC++ 2017 we will be able to use
constexpr in more places.

The static keyword was removed in a few places because it is redundant
to const/constexpr.

The effect on non-VC++ builds is unknown. It should be strictly
neutral or an improvement.

BUG=341941
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2942273002
Cr-Commit-Position: refs/heads/master@{#480928}
Committed:
https://chromium.googlesource.com/chromium/src/+/3aa1f0e28252bef52ab1869730ef...
==========

[commit-bot: I haz the power, 2017-06-20 20:17:23]

Committed patchset #7 (id:120001) as
https://chromium.googlesource.com/chromium/src/+/3aa1f0e28252bef52ab1869730ef...