[To reproduce I needed to brew install sdl2.]

Not many symbols changed in the two binaries. I think most of the size is attributable to _go.func.* getting much bigger. If you look at go tool nm <binary> | sort you can see this:

old

 45c5eb9 R _go.func.*
 4641a2a R _runtime.gcbits.*

new

 45c6759 R _go.func.*
 8cfb6ee R _runtime.gcbits.*

This means there's a whole lot more data in the symbol table. Not sure why that would be.

My current guess is this added line:

+       signalHistory [MaxSignalHistory]signal.SignalAttributes

MaxSignalHistory is 228 * 400 = 91200, and each entry is 40 bytes, for 3.6MB total.
If there were a composite literal making the containing type (a Television) that had non-zero but constant entries, then we'd put an instance of that type in read-only memory to construct one by copying from that read-only copy.
That doesn't account for all the space, but maybe there are several instances? At 3.6MB per it could add up quickly.

Changing MaxSignalHistory to 100 fixes the file size.

Changing MaxSignalHistory to 100 fixes the file size.

You're right, it does. I've replaced it with a make() in the latest code and that also fixes the problem and work perfectly. I would never have expected that to affect the executable size.

Thanks.

I'm still not sure exactly why it bloats the binary. There's only one &Television{} and it doesn't look like there is a static allocation there.

There are multiple non-pointer receivers for Television. It's also directly embedded in digest.Audio.

Ah, ok. Functions like this:

func NewAudio(tv television.Television) (*Audio, error) {

Require the compiler to describe to the runtime where all the pointers are in the arguments. The arguments are 3.6MB big, so that's lots of bits. And it isn't just once - it is multiple functions taking large types, times every callsite in those functions. It adds up quickly.

Conceivably we could figure out how to encode those bitmaps more succinctly (ala gcprograms, but for stack pointer maps), but generally passing around megabytes of arguments is probably going to suck for other reasons as well, so maybe not worth doing.

Interesting. I've genuinely learnt something here. I honestly wouldn't have thought that would affect executable size. Thanks for helping.

All right, I'll close this issue then. I think there are some possible ideas here (e.g. make binary space issues more discoverable) but nothing that wouldn't probably require a proposal first.