I enabled a new Mojo interface at r400746. It wouldn't have been compiled before then.
So there would be autogen C++ code for the Mojo structs, StructTraits and Mojo interface. There is also the client code that uses those things. It's a big chunk of code, so 20kb doesn't seem super unreasonable.
No, flipping to GN should not cause a 1MB size increase in chrome.dll (i.e., that would be unexpected). It is, however, completely plausible, and that would be the first thing I'ld like at in that revision range.
Should this be two different bugs, or are we just going to ignore the mac increase?
On my over-the-weekend gyp/gn build comparisons I see that on official builds chrome.dll increased by 0.8 MiB and chrome_child.dll shrunk by 0.3 MiB when switching from gyp to gn.
That's from 35.5 to 36.3 for chrome.dll and 44.2 to 43.9 MiB for chrome_child.dll.
On static_library builds both DLLs shrunk significantly when going from gyp to gn. On shared_library builds chrome.dll shrunk hugely when going from gyp to gn.
The only difference in my test builds was gyp versus gn. My build settings for the official build were:
gyp:
GYP_DEFINES=buildtype=Official
gn:
gn_args=target_cpu="x86";is_debug=false;is_component_build=false;is_official_build=true
At 4cc4f198b1, local build with settings shown in comment #9:
gyp official-build sizes:
37,176,832 chrome.dll
46,396,416 chrome_child.dll
270,848 chrome_elf.dll
450,048 chrome_watcher.dll
84,294,144 bytes
gn official-build sizes:
38,073,856 chrome.dll
45,983,232 chrome_child.dll
356,352 chrome_elf.dll
579,584 chrome_watcher.dll
84,993,024 bytes
The relative increase in chrome_elf.dll is particularly significant, and may allow for faster iteration on testing possible solutions since it will build relatively quickly.
Labels: -OS-Windows OS-Linux OS-Mac Summary: 50KB size regression on Windows at r400722 (was: 0.1%-2.7% regression in sizes at 400719:400784)
The second regression at #c4 was confirmed at #c5.
hlopko:
Now the first regression is the only unsolved item in this bug.
Can you check if your change at r400722 causing +50kB size regression is reasonable?
Yeah, r400722 added one pointer to WrapperTypeInfo, which has caused the 50 KB size regression.
+yukishiino +hpayer +jochen +mlippautz
I don't think we have tried hard to reduce sizeof(WrapperTypeInfo), so I'm guessing that there will be some low-hanging fruits there. Any thoughts?
One easy solution would be to use a union for |traceWrappersFunction| and |visitDOMWrapperFunction|.
I think we can move hasPendingActivity() from ActiveScriptWrappable to ScriptWrappable, and it reduces the size of WrapperTypeInfo.
My attempt is here: https://crrev.com/2265873003/
Oops, I forgot to add BUG= number in the CL (and to write the CL description).
https://crrev.com/2265873003/ has got landed. Let's see if the size reduces.
I was silly. The previous CL https://crrev.com/2265873003 reduced the size of WrapperTypeInfo, but increased the size of vtbl of ScriptWrappable and its subclasses. So, in total, the CL didn't reduce the binary size of Blink.
This time, https://crrev.com/2296573003 should reduce the size. On my local environment, the size of component-builds reduced by 400k bytes.
Let's see if the size will drop.
Unfortunately, I can't see an improvement on the original graphs. Even worse, the size is increasing from time to time.
Is there anything we can help on this issue? If not, is it okay to close this issue?
One important goal of this kind of monitoring is to detect changes that unexpectedly increase binary size drastically. So, if you or feature owners think it's expected or reasonable, IMO it's fine to close.
Ok, so as this was not unexpected increase in binary size, I'm closing this issue. Getting WrapperTypeInfo and ScriptWrappable smaller will be part of future work :)
Comment 1 by toyoshim@chromium.org
, Jun 21 2016