Request: Specifically mention the size of runtime.pclntab separately
siebenmann opened this issue · comments
As written up in Raphael Poss' Why are my Go executable files so large?, a great deal of the space usage of the runtime package as a whole is often in the runtime.pclntab data, which has a variable size that is based on how much (Go) code you have in your program. Because this is so big and not conventional code and data from runtime, I think it would be handy to make its size visible in goweight's output.
I took a look at the current code structure to see if I could spot an easy way to do this, but unfortunately I can't see one and so I can't propose a patch/pull request to implement this.
Sounds interesting -- after one knows about this, can one do anything about it? (i.e. reduce it?)
Based on reading the article, I think we can't reduce pclntab itself (except by having less code in the program), but maybe one can reduce the size of the rest of runtime under some circumstances. Right now I suspect that if you're using goweight to try to measure this sort of size reduction, you can't really see any effects on runtime's regular code because it'll usually be overshadowed by pclntab. Or maybe the rest of runtime will turn out to be a fixed size that we can't do anything about, and only pclntab really varies.
Also, I think that this means that pclntab's size and thus runtime's size varies based on how much code you use via import; if you use something big, you pay not just directly in its own code size (and the size of its imports), but also in a bigger pclntab. Today this is probably a bit hard to see or understand in goweight's report. You add or remove an import and not only does it appear or disappear in the size, but runtime's size varies mysteriously. Surfacing pclntab explicitly would help expose this unexpected additional cost of adding an import.
I understand, currently not sure I personally have the ROI motivation to implement, but will keep an eye open. My personal goal was to understand what libraries are heavy, and how I can replace those with something more lightweight or build-my-own in favor of size reduction.
Having said that -- would be happy to get some principles or ideas for how to really analyze, so that I can go straight ahead to implementation