runtime, cmd/compile: between Go1.25.5 and GoTip, with same generated ASM, document binary size increase for very small programs

[odeke-em]

Go version

Go 1.25.5

Output of go env in your module/workspace:

On Linux, Windows and Freebsd GOARCH=amd64

What did you do?

With this simple program https://odex.orijtech.com/p/3hiUoOSI or inlined below

package main

import "runtime"

func main() {
}

var _ = (*runtime.MemStats)(nil)

When compiled on Linux/amd64, the generated assembly is purported to be the same per https://odex.orijtech.com/p/3hiUoOSI#asm.diff

What did you see happen?

However when I examine the binary size per https://odex.orijtech.com/p/3hiUoOSI#bin-diff.size I see some changes in binary size on Linux/amd64 and Windows/amd64, FreeBSD/amd 64 but not on Darwin/amd64

And digging into packages and the symbols we see a culprit

Yet even no source diff between versions

What did you expect to see?

No size difference given code hasn’t changed nor has the generated assembly

Most definitely we might have some alignment issues that have caused this bloat.

Kindly cc-ing @prattmic @randall77 @mknyszek @cherrymui @ianlancetaylor.

Thank you and happy new year!

[gabyhelp]

Related Issues

• Binary/Compiled Size quintupled when the function is identical #43270 (closed)
• all: understand binary size changes vs 1.14 #38694
• cmd/compile: dramatic growth in binary size #42729 (closed)

Related Code Changes

• cmd/compile: teach prove about signed domain relations of constant integer Phi's
• cmd/compile: teach prove about signed domain relations of constant integer Phi's
• cmd/compile: add more integer-in-range optimizations
• cmd/compile: teach prove about the limits of sign/zero extensions and bool to uint8 conversions
• cmd/compile: don't CSE flag values in different blocks
• cmd/compile,sync: make accessing address of zero offset struct field inline cost 0
• cmd/compile: use shorter MOVs for clears of 9, 10, 11 and 12 bytes

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[cherrymui]

For a very small program, some binary size increase is expected, mostly due to the introduction of size specialized mallocs, as it adds a number of more malloc functions (https://tip.golang.org/doc/go1.26#faster-memory-allocation). I don't think it is related to Memstats. Could you try building it with GOEXPERIMENT=nosizespecializedmalloc ?

It is a small (~300K) fixed-size increase, not proportional to user code size. For a large binary, the increase is just a very small portion, so it is more ignorable.

Perhaps we should mention the binary size increase on the release notes? cc @matloob @mknyszek

[cherrymui]

but not on Darwin/amd64

Not sure how you measured this. I see the same binary size increase on darwin.

[odeke-em]

Could you try building it with GOEXPERIMENT=nosizespecializedmalloc ?

Sure @cherrymui, done and using TipNoSzMalloc shows that between tip and with that flag the binaries are a little smaller

And the binary is now:
TipNoSzMalloc is larger than Go 1.25.5 (+12.5%, 197.69 KB)

But no effect on runtime.MemStats

And then between TipNoSzMalloc vs GoTip, indeed I see many of the allocation functions

More complex program

For example a concurrency Google search from https://github.com/symonk/go-concurrency-deep-dive/blob/main/google_search_asynchronous/main.go per https://odex.orijtech.com/p/K-XKRBBG

You are correct that the size grows by but not by so much

However, the size of runtime.MemStats still grew by the same amount

[cherrymui]

I'm not sure I follow what specific issue you're concerned with. Is the ~2K size increase of the runtime.memstats symbol really a concern? We did add more fields to the symbol https://go-review.googlesource.com/c/go/+/658036/24/src/runtime/mstats.go#47 . runtime.memstats is a BSS symbol, so it doesn't occupy space in the binary, just the address space at run time. And 2K increase is such a small number. I don't think it is a concern. If you think it is a concern, could you clarify? Thanks.

[odeke-em]

Yeah it is no biggie then, indeed with my service I see the addition of that field as you showed too

Thank you very much @cherrymui and yes please proceed with the docs for the release notes