Tracking down large fuchsia binary size increase

[Andrew Brown]

Hi all,

I'm trying to track down an unexpectedly large binary size increase in Fuchsia on https://chromium-review.googlesource.com/c/chromium/src/+/5273743.

Compressed growth when submitting the CL was 49,152b and uncompressed 20,496b.

I compiled for fuchsia locally, with and without the change, to try and track things down. The binary_sizes.py script reports that my change actually *decreases* in size by 12,272b uncompressed and 8,192b compressed.

I installed and ran Bloaty; the VM size decreased by 10.8kB. The file size increased by 208kB, but those changes are made up of near a hundred thousand tiny, irrelevant changes: stuff like +30b in `blink::CSSParserFastPaths::ParseColor()` or +516b in `gen/v8/src/inspector/protocol/Debugger.cpp`. As best I can tell from Bloaty output, I would expect there to be a small, 1-2kB increase in uncompressed file size. I don't know where 20kB reported on the CL could be coming from.

Any advice would be greatly appreciated! Thanks :)

[Daniel Bratell]

This is a very late answer and you wisely proceeded when nobody said anything, but I'll put on the record what people (at least I) probably thought:

From your description sounds like you pushed some code over an inlining threshold. That is not at all actionable and the size delta is not large enough to panic. The compiler has heuristics that can be triggered by minuscule irrelevant changes and when that happens, at least when it's not connected to the actual change, we mostly shrug and move on. 

Someone else will eventually make another change where the binary randomly shrinks so it averages out.

/Daniel

--
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/12edf36d-08e7-438b-a893-56f5a4ae5dd5n%40chromium.org.