I can't reproduce the extra global variables on local builds, even with all of these settings:

is_chrome_branded = true
is_component_build = false
is_debug = false
target_cpu = "x86"
is_official_build = true

So, I need to bisect using canary builds. The regression appeared on Nov 11th. Therefore it probably first showed up in canary in 56.0.2917.0 (November 12th). That installer caused problems so I checked 56.0.2916.0 and 56.0.2918.0 and they both had the extra globals. I checked as far back as 56.0.2900.0 and the extra globals were there to, so maybe they have always been present in PGO builds with gn. In which case this regression is something entirely different.

Comparing the binaries shows that most of the size increase is from the .text segment - new code:

Size of 56.0.2916.0\chrome.dll is 41.041512 MB
      name:   mem size  ,  disk size
     .text: 33.090450 MB
    .rdata:  6.048750 MB
     .data:  1.219108 MB,  0.248320 MB
   .rodata:  0.003808 MB
    .gfids:  0.001052 MB
      .tls:  0.000025 MB
    _RDATA:  0.000288 MB
  CPADinfo:  0.000036 MB
     .rsrc:  0.175144 MB
    .reloc:  1.457552 MB

Size of 56.0.2918.0\chrome.dll is 41.920104 MB
      name:   mem size  ,  disk size
     .text: 33.764130 MB
    .rdata:  6.209102 MB
     .data:  1.229928 MB,  0.258560 MB
   .rodata:  0.003808 MB
    .gfids:  0.001052 MB
      .tls:  0.000025 MB
    _RDATA:  0.000288 MB
  CPADinfo:  0.000036 MB
     .rsrc:  0.175144 MB
    .reloc:  1.490956 MB

Change from 56.0.2916.0\chrome.dll to 56.0.2918.0\chrome.dll
     .text: 673680 bytes change
    .rdata: 160352 bytes change
     .data: 10820 bytes change
    .reloc: 33404 bytes change
Total change: 878256 bytes

Comparing the symbols between chrome.dll in 2916 and 2918 did show some non-trivial differences that, together with code size changes, could explain the regression:

Symbols that are in 2916.txt but not in 2918.txt
0       0        39492  2       gpu::kGpuDriverBugListJson
0       0         3904  3       kWebuiResources

Symbols that are in 2918.txt but not in 2916.txt
1       256     0       0       yy_ec
0       0        40008  2       gpu::kGpuDriverBugListJson
0       0        15718  2       gpu::gles2::ApplyFramebufferAttachmentCMAAINTELResourceManager::cmaa_frag_s2_
0       0        13246  2       gpu::gles2::ApplyFramebufferAttachmentCMAAINTELResourceManager::cmaa_frag_s1_
0       0         8192  2       gl::g_mantissa
0       0         5526  2       yycheck
0       0         5526  2       yytable
0       0         5072  3       gpu::gles2::GLES2DecoderImpl::command_info
0       0         5072  3       gpu::gles2::GLES2DecoderPassthroughImpl::command_info
0       0         3912  3       kWebuiResources
0       0         2180  2       yy_chk
0       0         2180  2       yy_nxt
0       0         1650  2       yy_base
0       0         1650  2       yy_def
0       0         1640  2       yy_accept
0       0          964  2       yy_rule_can_match_eol
0       0          838  2       yydefact
0       0          838  2       yypact

The extra global variables (ff_cos_* and ff_sin_*) in canary builds are a separate issue from this size regression. Those are triggered by full_wpo_on_official and are tracked by  bug 630755 .

The cause of this regression is unknown but it looks like gpu::gles2::* are related. gpu::kGpuDriverBugListJson and kWebuiResources have merely grown a little bit and are not the fundamental issue.

Or, the yy* variables could be the issue.

Any thoughts on why this regression was missed by the size steps? It was plenty large enough and sharp enough that it should have been automatically detected, if anything is. So, this suggests that the sizes steps are currently broken.

+fsamuel

We did detect the regression, but we use the perf builders because they have every revision so we don't need to bisect:
https://chromeperf.appspot.com/report?sid=360ede0bdbe363098ae928b46eed395c28e5fa687ad0cde6183fac88eafbf237&start_rev=431500&end_rev=431800

So this was filed in  bug 664481  and marked fixed. fsamuel: it doesn't look as if it were actually fixed though? I don't see the size come back down.

I'm glad it was detected. I expected the bug to show up on the sizes chart - are my expectations incorrect? Or did it not show up because the bug was tagged as fixed.

It seems that there is value in having the bug link show up on the sizes chart so that people who randomly browse the sizes chart can easily see the status of each blip and bump.

I checked a listing of large global variables in the latest canary and it shows all the new globals that are listed in comment #1 are still there. That suggests that the regression is not fixed. I have some tools and scripts for tracking regressions like this - techniques to figure out why particular object files are pulled in - so I could help with the investigation.

If 664481 is reopened then this could be closed as a duplicate.

+benhenry, do you know who owns the official builders/why they are sending sizes data? It's pretty confusing to users that we have the same data coming from two sources. As far as I can tell, it's strictly better just to have the perf builders computing sizes, because they are release official builds, they're part of our sheriffing rotations, and they give a build per revision so they don't need to be bisected.

I will reopen  bug 664481  and mark this as a duplicate.