Chrome installer binary size questions

[Antonio Maiorano]

Hello,

I'm a dev on the SwiftShader team, and am investigating making our Vulkan DLL (vk_swiftshader.dll) smaller as we prepare for the switch to SwANGLE. I've been documenting my efforts in this design doc. 

So far, I've been measuring the effects of different changes on the size of the DLLs I'm dealing with. However, as I understand it, I should be looking at the effects on the total download size of Chrome for our users. For this, I decided to build the "mini_installer" target, and take a look at the effects on "mini_installer.exe" as I make my changes. This is what I'm executing to build and print the size:

C:\src\chromium\src>del out\off\chrome.packed.7z && autoninja -C out\off mini_installer && dir out\off\mini_installer.exe && dir out\off\chrome.packed.7z

The first thing I noticed is that re-running this command with no local changes would produce a mini_installer.exe (and chrome.packed.7z) with varying sizes, for example:

09/01/2020 10:04 AM 62,250,496 mini_installer.exe 09/01/2020 10:07 AM 62,319,104 mini_installer.exe 09/01/2020 10:09 AM 62,348,800 mini_installer.exe 09/01/2020 10:11 AM 62,330,880 mini_installer.exe  

I investigated this, and determined this ~100KB variance in size comes from the differing timestamps of the files and directories that get archived from c:\src\chromium\src\out\off\gen\chrome\installer\mini_installer\mini_installer\temp_installer_archive. I hacked together this change to create_installer_archive.py to force a fixed time stamp on all the files and directories in temp_installer_archive, and sure enough, I now get deterministic build sizes for mini_installer.exe. I'm thinking of using this hack locally to see what impact my changes will have to the final download size.

Now my questions:

1. Does it make sense for me to be using the mini_installer target to measure the impact of my changes on the final download size? Is there a better way to measure this?

2. Is this ~100KB variance due to file/dir time stamps known and expected?

3. If the file/dir timestamp thing is known and expected, perhaps we can fix this problem. One thing I tried was to set the time stamp to a one taken when the script starts (see set_to_script_start_time in my CL), but this still produces archives of varying size. So one thought I had: force the same time stamp (say 2020/01/01 00:00:00, as I've done) in ALL builds, and make it so that the installer applies a valid time stamp post-extraction (this time stamp could be saved in a config file for the installer).

I hope this email was clear.

Thanks.

--

Antonio Maiorano

[Bruce Dawson]

I have not heard of this problem before, but it makes sense that varying timestamps could affect compression. It may be useful to apply the same timestamp to all files and directories always, both for consistency and to give a consistently smaller mini_installer. However I have no idea what the consequences of this would be.

--
You received this message because you are subscribed to the Google Groups "build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to build+un...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/build/CAJuY5KPd2T9btskt9W_sTaBbHNiYQYH14g_o6r54v30Hfe0ARA%40mail.gmail.com.

[Greg Thompson]

If you're making a local _official_ build, then looking at changes to the size of mini_installer.exe is the right thing for the impact on new installs. The other concern is the size of the first differential update when your change ships to stable channel. This is more challenging to evaluate, but can be done. You'll need to make before- and after- builds of mini_installer, and then build a diff updater from them. +Etienne Pierre-doray might be able to help you with command lines to accomplish this. Is the only difference the presence of a new DLL? If so, you likely don't need to bother -- the delta for new installs should be largely the same for diff updates.

[Etienne Pierre-doray]

 +Etienne Pierre-doray might be able to help you with command lines to accomplish this.

It might be relevant to watch for delta patch size with (generate chrome_diff.7z):

>> out/Release/zucchini gen out\old\chrome.7z out\new\chrome.7z chrome_patch.zuc

>> 7z a -t7z -m0=BCJ2 -m1=LZMA:d27:fb128 -m2=LZMA:d22:fb128:mf=bt2 -m3=LZMA:d22:fb128:mf=bt2 -mb0:1 -mb0s1:2 -mb0s2:3 chrome_diff.7z chrome_patch.zuc

I think that the 7z command is the same as what is used to compress chrome.7z into mini_installer.

[Antonio Maiorano]

Thanks, everyone, for your help. In our case, we're going to be removing 2 DLLs and adding 1, so I don't think there will be much value in looking at the diff installer. I went ahead and measured the impact of some of the changes I've been investigating on the size of the mini_installer (with the changes I made to fix the time stamps), and the findings are somewhat surprising:

Taken from my design doc at go/swangle-binary-size:

The following table shows the size of chrome.packed.7z, which is the LZMA-packed archive of the install payload that is linked into mini_installer.exe.

Step	Action	Size (bytes) of chrome.packed.7z	Difference (bytes)	Unpacked vk_swiftshader.dll size (bytes)	Difference (bytes)
1	None (GLES, no vk_swiftshader)	61,179,662	n/a	n/a	n/a
2	SwANGLE (remove GLES, add vk_swiftshader)	61,192,431	12,769	4,324,352	n/a
3	Optimize for size	61,212,532	+20,101	3,948,032	-376,320
3	Remove spriv-val	61,131,056	-61,375	3,815,424	-508,928
3	Remove ASTC	61,277,771	+85,340	4,290,560	-33,792

The Step column is to help understand the order in which the changes are applied. Basically, the three step 3's are the optimizations I've attempted thus far. As you can see, although all three reduce the size of our vk_swiftshader.dll, two of them actually increase the size of the mini_installer (of chrome.packed.7z). It's pretty surprising, especially since the "optimize for size" change is - as I understand it - something we generally apply throughout Chrome, and yet, doing so for SwiftShader actually increases the size of the mini_installer. We surmise that optimizing for speed possibly produces more common patterns of code that are more easily packed, but we're not sure.

Ultimately, keeping in mind that there's already the ~100K variance in installer size due to the timestamp problem, we may just go ahead and do nothing when making the switch to SwANGLE. However, this does raise the question of what the general guidelines are for making sure we don't increase Chrome's download size as developers. I'm not very familiar with the Chrome bots yet, but I understand that we do track binary size, and report when significant changes to it occurs. Is there more information on this somewhere? Is there documentation with guidance on binary size?

Thanks,

- Antonio Maiorano

--

Antonio Maiorano

[Sébastien Marchand]

We don't currently use "optimize for size" on official builds, we use O2 (Optimize for speed) combined with PGO, the idea is to let the compiler decide what level of optimization to use (using the PGO profile data). It doesn't work so well in practice (PGO had a significant impact on binary size) and we should eventually look at improving this . 

mini_installer is a packed archive, so it's possible that the size optimization makes the code less compressible... 

 

Ultimately, keeping in mind that there's already the ~100K variance in installer size due to the timestamp problem, we may just go ahead and do nothing when making the switch to SwANGLE. However, this does raise the question of what the general guidelines are for making sure we don't increase Chrome's download size as developers. I'm not very familiar with the Chrome bots yet, but I understand that we do track binary size, and report when significant changes to it occurs. Is there more information on this somewhere? Is there documentation with guidance on binary size?

There's no real guidance on Windows. We do have some perf bots that track binary size and it's monitored by the Perf sheriffs.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/build/CAJuY5KMpsGn%3DBxvM%2BwYksp2S9t_VhzBy8PSvfBZaSXs0frrg%2Bg%40mail.gmail.com.

--

Sébastien Marchand | Software Developer | sebma...@google.com 

[Andrew Grieve]

Regarding the 100kb variance, having reproducible builds is definitely a problem worth solving. Please file a bug and follow up on that! It's a great find!

Maybe set timestamps to 0, and then when extracting, set them all to the timestamp of the installer binary?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/build/CAPONGC2oMCVUumgLbdvjSNxMJYNep6fCb70stASm6k3Q4CCdRQ%40mail.gmail.com.

[Antonio Maiorano]

On Thu, Sep 3, 2020 at 11:17 AM Andrew Grieve <agr...@chromium.org> wrote:

Regarding the 100kb variance, having reproducible builds is definitely a problem worth solving. Please file a bug and follow up on that! It's a great find!

Thanks, I'm doing exactly that!

 

Maybe set timestamps to 0, and then when extracting, set them all to the timestamp of the installer binary?

Yes, that's exactly what I would recommend trying to do.

Cheers,

Antonio

--

Antonio Maiorano