Given how much Go already does for one—and given the static nature of Go binaries—is there any reason why the compiler shouldn't reorder structs so that they take the least space possible?<p>I can see that that would prevent one from reliably dumping memory to disk and then re-reading it, but It's hardly reliable to do that <i>anyway</i>. One should be using an encoding anyway…
If you're like me and had no idea what<p>_ struct{} // to prevent unkeyed literals<p>means, some explanation turns up here: <a href="https://groups.google.com/forum/#!topic/golang-nuts/NSjVW82i0mY" rel="nofollow">https://groups.google.com/forum/#!topic/golang-nuts/NSjVW82i...</a>
The article mentions that the "Go spec says the address of a struct’s fields must be naturally aligned", and seems to take for granted that is necessary for speed. A separate question would be whether it actually helps performance.<p>For modern x64/x86 the answer seems be to "no": <a href="http://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/" rel="nofollow">http://lemire.me/blog/2012/05/31/data-alignment-for-speed-my...</a><p>Would it make sense for the Go spec to drop the alignment requirement? I'd think that a smaller memory footprint would be the better choice, and I'd think that interoperability would be better served by allowing arbitrary alignments.
Side question: who is in that animated gif about a quarter of the way down the page (fingers to temples, starbursts in background)? I see that around on dev blogs quite a bit.