The biggest and sixth biggest functions (by bytes of machine code) in chrome.dll on Windows are GetPathForVectorIcon* functions. There sizes and names are:

195980: struct gfx::PathElement const * __cdecl gfx::GetPathForVectorIcon(enum gfx::VectorIconId)
50468 :struct gfx::PathElement const * __cdecl gfx::GetPathForVectorIconAt1xScale(enum gfx::VectorIconId)

Looking at the assembly language shows why - the arrays are being constructed at run-time. This also means that they are all creating per-process private data instead of constant data. Typical machine code looks like this:

const PathElement* GetPathForVectorIcon(VectorIconId id) {
...
0FBCC4B0 6A 05                push        5  
0FBCC4B2 B9 30 5F 0E 12       mov         ecx,offset path (120E5F30h)  
0FBCC4B7 E8 8E FF FF FF       call        gfx::PathElement::PathElement (0FBCC44Ah)+0  
...
0FBCC4BC F3 0F 10 0D 80 8F 06 12 movss       xmm1,dword ptr [__real@40c00000 (12068F80h)]  
0FBCC4C4 B9 34 5F 0E 12       mov         ecx,offset path (120E5F30h)+4  
0FBCC4C9 E8 8A FF FF FF       call        gfx::PathElement::PathElement (0FBCC458h)+0  


This same pattern repeats for each element in each array - push or load a constant integer or float, load the address of the element, then call the constructor. The runtime cost of this is negligible, but the wasted code space, .reloc entries, and private memory are unfortunate.

Using constexpr guarantees that the arrays will be done as data instead of code, and actually *decreases* the compile time for vector_icons.cc on Windows.

The effects on other platforms has not been measured but using constexpr should not make things any worse.

It looks like this was originally introduced by crrev.com/1219293004 and is related to crbug.com/505953.

Local tests suggest that the total savings for x86 chrome.dll are:
       .text: -257152 bytes change
      .rdata:   47984 bytes change
       .data:  -57344 bytes change
      .reloc:  -43820 bytes change
Total change: -310332 bytes

In addition to the 257,152 bytes of code reduction and 43,820 bytes of relocation reduction this change moves about 50 KB of data to the read-only data section, instead of having it be per-process private data.