Size visualization of Go executables using D3

&gt; as discussed in my previous article [1], Go uses memory instead of registers to pass arguments and return values across function calls.<p>[1] <a href="https:&#x2F;&#x2F;science.raphael.poss.name&#x2F;go-calling-convention-x86-64.html" rel="nofollow">https:&#x2F;&#x2F;science.raphael.poss.name&#x2F;go-calling-convention-x86-...</a><p>This is very surprising for a language that targets somewhat high performance.<p>Looks like it&#x27;s a 5-10% performance hit, but makes it easier to provide good backtrace information: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;18597" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;18597</a>

Really interesting results and analysis, but small nit:<p>&gt; there is about 70MB of source code currently in CockroachDB 19.1, and there was 50MB of source code in CockroachDB v1.0. The increase in source was just ~140%<p>That&#x27;s a 40% increase, not 140%. This happens on all percentage calculations throughout the article.<p>That said, super interesting discovery.

go minor releases make a surprising difference - you&#x27;ll see a big difference if compiling the same project with go-1.10.z vs go-1.12.z<p><a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;27266" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;27266</a><p>a very recent cause of pclntab getting huge is adding preemption safepoint info for every line&#x2F;instruction range, and they&#x27;re looking at alternatives:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;24543" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;24543</a>

Another utility (cli based) for investigating go binary sizes is `goweight`:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;jondot&#x2F;goweight" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jondot&#x2F;goweight</a><p>Written about here:<p><a href="https:&#x2F;&#x2F;medium.com&#x2F;@jondot&#x2F;a-story-of-a-fat-go-binary-20edc6549b97" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@jondot&#x2F;a-story-of-a-fat-go-binary-20edc6...</a>

<i>The purpose of this data structure is to enable the Go runtime system to produce descriptive stack traces upon a crash or upon internal requests via the runtime.GetStack API.</i><p><i>In other words, the Go team decided to make executable files larger to save up on initialization time.</i><p>Something about this whole thing just seems <i>wrong</i>. How often does (perhaps <i>should</i>) an application crash? How often does (again, perhaps <i>should</i>) it need to retrieve its own stack? ...and <i>how much</i> of the binary is being taken up just for that purpose?<p><i>Of size&#x2F;performance trade-offs and use cases</i><p>Why is startup time even the question when the common-sense approach is to simply compress this rarely-used table and decompress it <i>upon the first time it&#x27;s used</i>, not upon every startup? That&#x27;s assuming it is always absolutely necessary to have in the first place, since loading a huge executable isn&#x27;t going to be fast anyway.<p>I feel like this is a case of &quot;the tail wagging the gopher&quot;.

Would it be possible to pass a flag to go build to change runtime.pclntab to the pre Go 1.02 implementation?<p>I don&#x27;t actually have the author&#x27;s usecase though, I tend to build microservices in Go!

I put together a little demo looking at the impact of using fmt vs os for Hello, World.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;allingeek&#x2F;fmt-vs-os" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;allingeek&#x2F;fmt-vs-os</a>

Could we see a comparison with both `-ldflags &#x27;-s -w&#x27;` and `CGO_ENABLED=0`?<p>I feel like this would solve:<p>&gt; the Go standard library is not well modularized; importing just one function (fmt.Println) pulls in about 300KB of code.