All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=641017

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgvuSrpgsM


Bot(s) for this bug's original alert(s):

win

Looks like there is only one revision in the range for this Size spike.
https://chromium.googlesource.com/chromium/src/+/3e80255c5139698d5fca9d8f1595a307f6cb3639

brucedawson@, Do you see this related to your CL, if not please re-assign this bug back to me.

Yep, that's my change. Known and expected. I changed the optimization settings for skia from optimize-for-size to optimize-for-speed, so it got faster but bigger.

This was necessary in order to fix a speed regression ( crbug.com/632651 )

In my testing the change increased the size of chrome_child.dll from 48,593,408 to
49,213,440 bytes. However the gyp version at the same position was 49,032,192 bytes. So, most of the change was just giving back some unintentional gains from the gyp to gn transition.

I'm tempted to close this as WAI but lets leave it open. I have a few tricks that should let us reduce the size a bit. My goal would be to reduce the size by ~180 KB. Reducing the size by the full amount of the regression is not practical or realistic.

Adding kerz who owns sizes as part of the release process, and grt who is the owner for Windows sizes, as FYI.

I'm pretty sure I have some sizes credits from reducing the size of chrome_child.dll so much a few weeks ago (including crrev.com/2172033002). I'd like to apply some of those credits to this bug please.

sgtm

Investigating this now.

My first observation is that this is worse than I thought and it also exposed a previously unnoticed regression. My change (crrev.com/2270693006) changed skia from default_optimization to optimize_max. I new that this made chrome_child.dll larger by about 620,032 bytes, so the increase in (64-bit) chrome_child.dll by 739,800 was not too surprising.

However at the same time (64-bit) chrome.dll got larger by 765,400 bytes which is surprising because it doesn't use skia, I thought.

The real surprise was (64-bit) chrome.exe. First, it got larger by 829,440 which is odd since it definitely shouldn't be using skia. But even more surprising is that its base size was 3,170,820 bytes. This regressed (without being noticed?) by 1,991,680 bytes over a month ago, in this innocuous range:

git log  002fbfa..a0c9ca4

I'm tracking the chrome.exe size increase from Aug 11 in  issue 647223 . I believe I have rejiggered things to avoid pulling //ui into chrome.exe in a CL out for review.

 Bug 630755  is a related bug. I filed it to remind me to do more binary savings when I had a chance and it contains a list of gn-only globals, which are good starting points.

Perf sheriff ping

brucedawson@ -- Is there anything else that we should do to follow up here?

Closing as a duplicate of the other bug. There should be a few more gains available and they (skia changes, for instance) are being tracked on that bug.