strip / reduce module compile size

[Tony M]

Thank you to github.com/jondot/goweight I was able to determine the compiled module sizes (below). Heavy hitters are net/http & protobufs, among 100+ others .  Total compile size is 22MB . 

Are there any tools or flags that can help strip or reduce some of the compiled code from these modules? 

 goweight gcloud-lite
   11 MB runtime
  7.7 MB net/http
  5.3 MB google.golang.org/protobuf/internal/impl
  5.2 MB google.golang.org/api/storage/v1
  4.5 MB cloud.google.com/go/storage
  4.2 MB golang.org/x/net/http2
  4.0 MB golang.org/x/sys/unix
  3.8 MB net
  3.8 MB cloud.google.com/go/storage/internal/apiv2/storagepb
  3.6 MB crypto/tls
  3.4 MB google.golang.org/grpc
  3.4 MB cloud.google.com/go/pubsub/apiv1/pubsubpb
  3.2 MB cloud.google.com/go/pubsub/apiv1
  2.6 MB reflect
  2.4 MB google.golang.org/grpc/internal/transport
  2.3 MB google.golang.org/protobuf/internal/filedesc
  2.1 MB cloud.google.com/go/pubsub
  1.9 MB google.golang.org/protobuf/types/descriptorpb
  1.9 MB math/big
  1.9 MB encoding/gob
  1.8 MB go.opencensus.io/plugin/ochttp
  1.7 MB syscall
  1.7 MB cloud.google.com/go/storage/internal/apiv2

[50+ more]

[robert engels]

Something doesn’t seem right... You state the total compiled size is 22MB, but the first 3 entries combined are more than that.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/678b11f8-beb4-4024-91c7-1a7b18835a28n%40googlegroups.com.

[Dan Kortschak]

On Fri, 2024-06-14 at 19:35 -0500, robert engels wrote:
> Something doesn’t seem right... You state the total compiled size is
> 22MB, but the first 3 entries combined are more than that.

It looks like goweight just gets the size of the .a files that are
generated during the build and returns the sum of that for each of the
dependencies. So it does not take into account the the linker's removal
of unused things.

[Peter Galbavy]

If end binary size is a constraint, try "upx" to compress the end binary. I regularly get 3x compression - but lose all debug options, obviously. Works on most OSes for executables.

[Tobias Klausmann]

Hi!

On Sat, 15 Jun 2024, Peter Galbavy wrote:
> If end binary size is a constraint, try "upx" to compress the end binary. I
> regularly get 3x compression - but lose all debug options, obviously. Works
> on most OSes for executables.

Be aware that there are further consequences to using upx, beyond "no
debug symbols". Startup is likely slower, and even steady-state runtime
performance may suffer (this is anecdotal, but I have no reason to doubt
it).

For embedded systems and similar scenarios, it still is a very valuable
tool.

Best,
Tobias

[Peter Galbavy]

These were my original worries, but as a human CLI user I notice no start-up time impact; I am certain if you benchmark it then there will be a small delay, but it's well under the human perception limit.

Runtime performance, ditto.

As always, YMMV and do your own due diligence!

[Tony M]

Are there other tools that may show the final size? I'd like to see if there are more aggressive flags to strip unused code? It's a simple module, with some grpc (protobuf), http . I don't believe all these code paths are in scope for my 200 LOC

[Zxilly Chou]

Please try https://github.com/Zxilly/go-size-analyzer . I created this based on reverse engineering, so only the bytes in the final build will be count.