New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: object file much larger than final executable #50438
Comments
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 |
Here is a single file of about 1500 lines. https://gotipplay.golang.org/p/kMBLHxigsDo
|
With the test case above, The largest symbol in the object file is
It's 30111 bytes (according to This may be working as expected, but CC @randall77 @danscales in case it is not. |
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. Because I think It would be better not to use type parameters with interface types in the production to reduce compile time. |
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 |
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. |
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. |
@danscales This is in the 1.18 milestone; time to move to 1.19? Thanks. |
Yes, I'll move to 1.19. Thanks! |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
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?
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.
It will not become a problem right now, but I think it will become a big problem as more and more projects use generics.
The text was updated successfully, but these errors were encountered: