how to actually measure binary size locally? or compare desktop binary size change for a patch?

[Daniel Murphy]

Hi!

I could have sworn I saw gn config somewhere - but how do I build so that I get the smallest / official build / binary size? I want to experiment with measuring the cost of protobuf full vs deleting the hand-rolled code everywhere which ends up also taking up a lot of binary size vs doing a reflection situation.

Anyways - yeah is there a way, maybe even better, for me to have a patch and use a trybot or something to see the binary size diff for desktop?

Dan

[Daniel Murphy]

These are my gn args:

is_debug = false
is_java_debug = false
symbol_level = 0
is_component_build = false
blink_symbol_level=0
v8_symbol_level=0
is_official_build = true
is_chrome_branded = true

[Daniel Murphy]

I just found these - the gn args of the android compile size generator:

android_channel = "stable"
debuggable_apks = false
ffmpeg_branding = "Chrome"
is_high_end_android_secondary_toolchain = false
is_official_build = true
proprietary_codecs = true
symbol_level = 1
target_cpu = "arm64"
target_os = "android"
use_reclient = false
use_remoteexec = true
use_siso = true
v8_is_on_release_branch = true

[Erik Staab]

It's not what you're asking for but I would be interested in the impact on compiler input size for the sake of build times. You can trigger the Linux compile-size builder or follow the more involved steps in https://chromium.googlesource.com/chromium/src/+/main/docs/speed/binary_size/compile_size_builder.md#run-a-local-compile_size-check.

--
You received this message because you are subscribed to the Google Groups "binary-size" group.
To unsubscribe from this group and stop receiving emails from it, send an email to binary-size...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/binary-size/87cdd8a8-c6a6-4420-bca7-9e71f242d69bn%40chromium.org.

[Daniel Cheng]

Measuring binary size isn't easy and there's not really one right answer.

• There's the android-binary-size bot. The arm32 results are pretty useful but aren't always indicative of how binary size will be affected elsewhere.
• The arm64 results from android-binary-size are a bit less trustworthy, as binary size can vary wildly depending on the PGO profile being used. For accurate results, you should be regenerating the PGO profile and then rebuilding using that profile... but that's not implemented (yet?)
• Desktop builds have the same issue with PGO. You'll want to make an official build, but then you really need to be generating your own PGO profiles for an apples-to-apples comparison. Or you could disable use of the PGO profile altogether and hope that it's good enough.

Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/binary-size/CAN60ya%2BtCPq4kqEp%3D5d2wxkHi35cr3dUiu-6-yQsbok39PmS7Q%40mail.gmail.com.

[Daniel Murphy]

I just found the diagnose bloat script which SEEMS like it has good data? I'm not sure if I should be having it set the symbol level to 0 instead of 1, but that seems to give good results.

I've been using it in the continued investigation around protobuf LITE_RUNTIME vs CODE_SIZE, especially when people hand-roll functionality that is more efficiently solved (code size wise) via reflection, like equality and base::Value serialization.

[Andrew Grieve]

It's been forever since I tried diagnose_bloat.py on Linux, but at one point it worked :P

The tool should work well for arm32 and arm64 Android, but has the same caveats as the trybot (that PGO makes arm64 number untrustworthy)

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/binary-size/CA%2B4qT30hkX8pqDtoxS9NmHhkg9RNjmMR_GUGbt4z%3DsN9qVmuoA%40mail.gmail.com.

[Daniel Murphy]

It seems like it's working.... ok? It definitely changes correctly. It would be good to know if it's over-estimating!

https://chromium-review.googlesource.com/c/chromium/src/+/6700957 is my latest patch trying to show tradeoff between protobuf lite and full+code_size optimization.

The main issue is the static initializers? Maybe? 500kb binary size increase (which can think if more protobufs use CODE_SIZE) isn't good, but that can change.

I don't think the static initializers can change, unless we change protobuf code or allow-lost them.....

[Daniel Cheng]

That's a lot of static initializers. Is there no way to help with that?

Daniel

[Daniel Murphy]

Google searching didn't say anything in particular- protobufs create a static global map of the descriptors/ symbol references. Perhaps it could turn into a constexpr? Actually I don't think it can, as it's basically dynamically adding stuff when the file is compiled? Idk. If you look at the bottom of one of the non-lite proto pb.h files, I think it's there. Or maybe the .cc one? I forget.