I have come up against something a bit strange and interesting that I didn't really expect from the Go compiler.
I have a main which uses a structure created in a package, which contains a whole load of references to other packages. What I discovered is that even though only one of these included packages is used, the whole set still gets included in the binary. Am I right in saying that packages create a linker object file, as a whole, and every package imported is also linked? In the case of my application it means I now have to manually break up a whole load of nice pretty neat declarations into pieces that return generator functions, and each part has to come from a different package, meaning a folder and one tiny little source file. I couldn't find any reasonable terms that explained Go's linking mechanisms but it dawned on me as I thought about how each folder in the tree creates a binary object that is stitched together in the final binary, that there's really no way around this, and I suppose it makes nice neat little bite sized source files but for my case it was a surprise I hadn't expected. After building a giant conglomeration I realised for some cases (namely, a backend for a mobile app) that one has to design the folder tree to split the parts. It's something to keep in mind for multi-function binaries if you want to also offer single function binaries for specific parts that are only needed alone. I am probably, as usual, doing something unconventional and running up against things that nobody else ever thought of and discover something about a system that isn't obvious until you think about it, when one intends to do some particular thing. In terms of memory utilisation, there is really not a great deal of difference in terms of performance, I presume, except providing the ability to cut up the whole thing into small pieces, a tiny amount extra on disk but I presume the final memory use, since all is a monolithic (more or less) static binary, that once it unwraps all the entry points and relative references that there isn't (much) extra in memory. I suppose also if one is targeting a constrained environment, it would make sense to use -s -w to strip out the debug symbols. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/36de6c0d-23fe-4dfa-ad9a-89d9734c9701%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
