i did a quick experiment with getting rid of strings - made cmd/link.ftabaddstr a no-op. that didn't actually save that much: i got rid of all stringtab and it saved about 600K of the original 2.8M pclntab, or 20%, give or take. the remainder compresses to about 800K with xz -9, so there's quite a bit of redundancy there. all of the above is for ARM builds, for amd64 there's even more due to 64-bit pointers, higher bytes of which are mostly zeroes. for this particular binary:
pclntab.amd64 - 3341578 pclntab.amd64.nostr - 2728272 pclntab.arm5 - 2844248 pclntab.arm5.nostr - 2246896 On Tuesday, December 17, 2019 at 12:09:15 PM UTC, Deomid Ryabkov wrote: > > running into the same issue: embedded system, fat Go binaries, 20% is the > symbol table. > +1 for slimming it down, perhaps with full non-stripped version emitted > separately to analyze stack traces later (like it's common to keep > non-stripped binaries for that reason). > is there an issue already for that? should one be created? > > On Friday, April 5, 2019 at 3:07:10 PM UTC+1, Ian Lance Taylor wrote: >> >> On Fri, Apr 5, 2019 at 5:33 AM Steeve Morin <steev...@gmail.com> wrote: >> > >> > Removing the function names and file information probably constitutes >> the >> > most part of the size, I would guess. >> > >> > Do you suggest stripping it as a post processing step or modifying the >> linker >> > to not emit the strings in the first place? >> > I'm not fond of adding a new flag to the linker, but it may not be such >> a bad >> > idea in a mobile context to remove function names and file information. >> >> I doubt it's feasible to strip the names after the fact; I think it >> would have to be a linker option. (I'm not promising that such a >> linker option would be accepted into the main tree.) >> >> > I would assume most of that happens in cmd/link/internal/ld/pcln.go >> right ? >> >> As far as I know, yes. >> >> Ian >> >> >> > On Friday, April 5, 2019 at 12:14:49 AM UTC+2, Ian Lance Taylor wrote: >> >> >> >> On Thu, Apr 4, 2019 at 2:32 PM Steeve Morin <steev...@gmail.com> >> wrote: >> >> > >> >> > We are big Go users on Android and iOS thanks to golang/mobile. >> >> > >> >> > Lately we were doing some size profiling and stumbled upon >> runtime.pclntab, >> >> > which in our case represents almost 20% of the file size according >> to bloaty. >> >> > Now I understand that it's used for things like runtime.Caller and >> panics. >> >> > That said, in a mobile context panics are not that useful as this >> job is handled by >> >> > services like Crashlytics and DWARF. >> >> > >> >> > So we were wondering if it would be possible to strip it (or not >> emit it altogether) >> >> > and what would be the consequences/limitations of that? >> >> >> >> The consequences of removing pclntab would be fairly severe. You >> >> wouldn't just lose runtime.Callers and stack traces and tracing and >> >> profiling. The pclntab section is also used by the garbage collector >> >> to traverse the stack, and by the stack copying code. I doubt that >> >> many substantial Go programs would still work correctly. >> >> >> >> That said you could in principle drop part of pclntab with less severe >> >> consequences, such as removing the function names. I don't know of >> >> any supported way to do that, though. >> >> >> >> Ian >> > >> > -- >> > 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 golan...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> > -- 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/ecfe5aaf-5578-41c0-b84e-e7a4a4751a69%40googlegroups.com.
