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
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
On Fri, Apr 5, 2019 at 5:33 AM Steeve Morin 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?
>
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
On Thu, Apr 4, 2019 at 2:32 PM Steeve Morin 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
Hey guys,
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 p
