Description
What version of Go are you using (go version
)?
$ go version go version devel go1.18-f154f8b Tue Jan 4 22:27:20 2022 +0000 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/gura/Library/Caches/go-build" GOENV="/Users/gura/Library/Application Support/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/gura/go/pkg/mod" GONOPROXY="*.uangel.com" GONOSUMDB="*.uangel.com" GOOS="darwin" GOPATH="/Users/gura/go" GOPRIVATE="*.uangel.com" GOPROXY="https://proxy.golang.org,direct" GOROOT="/Users/gura/sdk/gotip" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/Users/gura/sdk/gotip/pkg/tool/darwin_amd64" GOVCS="" GOVERSION="devel go1.18-f154f8b Tue Jan 4 22:27:20 2022 +0000" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/gura/test/fp/go.mod" GOWORK="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/y1/bngm83dj5_5dcsgh9yrwvpm00000gp/T/go-build228120003=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
$ git clone -b build-cache https://github.com/csgura/fp.git
$ cd fp
$ gotip clean -cache
$ du -hs ~/Library/Caches/go-build/
8.0K /Users/gura/Library/Caches/go-build/
$ gotip test ./...
$ du -hs ~/Library/Caches/go-build/
1.4G /Users/gura/Library/Caches/go-build/
What did you expect to see?
A build cache directory of a reasonable size ,
or
Warning about incorrectly used generic type.
What did you see instead?
$ du -hs ~/Library/Caches/go-build/
1.4G /Users/gura/Library/Caches/go-build/
Please excuse my poor English.
It seems to be related to this issue as well. #50204
I have written some algebraic data types to test the generic of Go 1.18.
( https://github.com/csgura/fp.git )
After running the tests, I noticed that the build cache was using a very large amount of disk.
I guess the cause lies in the some recursive type ( HList and curried Func ) and the interface type that uses the type parameter.
When I modified the code so that a generic interface type does not return other generic interface type,
The size of the build cache has been significantly reduced.
This fix is applied in the master branch.
$ git checkout master
$ gotip clean -cache
$ gotip test ./...
$ du -hs ~/Library/Caches/go-build/
176M /Users/gura/Library/Caches/go-build/
It will not become a problem right now, but I think it will become a big problem as more and more projects use generics.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Activity
rsc commentedon Jan 5, 2022
It would help if you could provide a small single source file that produces a large output using
go tool compile -o x.a x.go
csgura commentedon Jan 6, 2022
Here is a single file of about 1500 lines.
https://gotipplay.golang.org/p/kMBLHxigsDo
[-]cmd/compile: Size of 'Caches/go-build' directory is too large.[/-][+]cmd/compile: size of 'Caches/go-build' directory is too large[/+][-]cmd/compile: size of 'Caches/go-build' directory is too large[/-][+]cmd/compile: object file much larger than final executable[/+]ianlancetaylor commentedon Jan 6, 2022
With the test case above,
go tool compile foo.go
produces a file that is 70173802 bytes.go tool link foo.o
produces a file that is 2400985 bytes. So the final executable is about 3.5% of the size of the object file.The largest symbol in the object file is
It's 30111 bytes (according to
go tool nm
). It does not appear in the final executable. In fact, none of the 100 largest symbols in the object file appear in the executable.This may be working as expected, but CC @randall77 @danscales in case it is not.
csgura commentedon Jan 6, 2022
https://gotipplay.golang.org/p/8WZz12Ay6vz
It is almost the same code, but the Option, Try , HCons and Iterator types are changed to a struct type.
The object file size has been reduced to 17436020.
It seems that object files are created inefficiently when generic interfaces refer to each other.
I know that it works as expected,
but wouldn't it be better to output a warning message when an object file is created inefficiently like that?
Because I think It would be better not to use type parameters with interface types in the production to reduce compile time.
danscales commentedon Jan 6, 2022
As Ian's symbol example shows, the symbols can be quite large for the names of instantiated functions/methods, when the type arguments are instantiated types that are nested and the descriptions of some of the underlying types (e.g. interfaces) are large. For the name of a shape type (the proxy type standing for all the types that a particular instantiation will handle), we use the standard printing (via LinkString) of the shared underlying type (e.g
go.shape.int64_0
orgo.shape.interface { M(); String() string }_0
orgo.shape.struct { p.x int8; p.y float64 }_0
. Using the name of the underlying type is easiest so that we have a unique name across packages. For Go 1.19, we could try to use shorter, unique, but memo-ized names, but then we would probably need extra coordination across compilations (using the build cache?). Or, if a shape name gets really large (> 50 characters), maybe we could replace it with an MD5 hash?ianlancetaylor commentedon Jan 6, 2022
No. This is something for a release note, not a compiler warning. Everything works correctly, it just takes more space than expected. The compiler never issues warnings anyhow.
akutz commentedon Jan 25, 2022
FWIW, I've written a few tests to show that while package archives are definitely larger (usually 2x), the resulting binary executable shows no real difference -- https://github.com/akutz/go-generics-the-hard-way/blob/main/06-benchmarks/03-file-sizes.md.
ianlancetaylor commentedon Jan 29, 2022
@danscales This is in the 1.18 milestone; time to move to 1.19? Thanks.
danscales commentedon Jan 29, 2022
Yes, I'll move to 1.19. Thanks!
27 remaining items