Binary/Compiled Size quintupled when the function is identical

[kevin-matthew]

What version of Go are you using (go version)?

$ go version
go version go1.14.6 linux/amd64

Does this issue reproduce with the latest release?

Unknown

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/k/.cache/go-build"
GOENV="/home/k/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/k/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build589560545=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Compiled and compared these two files:

package main
func main() {
	println("Hello World!")
}
// go build -o test.out test.go && ls -lh test.out
// 1.2M test.out

package main
import (
	"net/http"
)
func main() {
	cook := http.Cookie{
		Name:       "Hello World!",
	}
	println(cook.Name)
}
// go build -o test.out test.go && ls -lh test.out
// 6.6M test.out

What did you expect to see?

I expected both of the snippets above to produce a similar-sized binary.

What did you see instead?

The one that included http package was much (5x) larger even though it was identical in function. Leaving me to believe that including packages leaves tons of "dark assembly" that is never accessed by the program itself. And after checking the binary symbol tables with nm -D, I find that the exports are the same too (none). Meaning there's a ton of unused and/or impossible-to-use cruft when compiling imported packages.

I feel as though a compiler's job is to be smart enough to not include code that won't/can't be used. Which is certainly not happening here.

[randall77]

The problem is the init functions in net/http, which drag in most of the package with it.

See #38450, #19533 and a bunch of issues those reference.
See also https://go-review.googlesource.com/c/go/+/268899/ , a recent CL in this area.

We know this is a problem, but the fixes aren't simple.

Should we close this as a dup? It's a good test case, but I think the other issues cover most of the ground here.
@jeremyfaller

[jeremyfaller]

I agree with Keith. I think this is a duplicate. Marking closed.