Skip to content
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

Jump to bottom

cmd/compile: unnecessary hash/eq functions for slice literals #30449

Open
neild opened this issue Feb 27, 2019 · 3 comments
Open

cmd/compile: unnecessary hash/eq functions for slice literals #30449

neild opened this issue Feb 27, 2019 · 3 comments
Labels
binary-size compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. ToolSpeed
Milestone
Backlog

Comments

@neild
Copy link
Contributor

neild commented Feb 27, 2019

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

$ go version
go version go1.12rc1 linux/amd64

Consider this package:

package bloat
var x []interface{}
$ go build -o bloat.a .
$ ls -l bloat.a
-rw-r--r-- 1 dneil primarygroup 778 Feb 27 15:23 bloat.a

Now consider the case where we initialize the var x:

package bloat
var x = []interface{}{0, 1, 2}
$ go build -o bloat.a .
$ ls -l bloat.a
-rw-r--r-- 1 dneil primarygroup 4030 Feb 27 15:28 bloat.a

The object file for the latter package contains eq and hash functions for [3]interface{}, which appear to account for much of the size increase:

$ go tool pack x bloat.a
$ go tool objdump -S bloat.a | grep ^TEXT
TEXT type..hash.[3]interface {}(SB) gofile..<autogenerated>
TEXT type..eq.[3]interface {}(SB) gofile..<autogenerated>

There is no need for these functions, however; the only use of [3]interface{} is to initialize a []interface{}, and there is no way to recover the array type from that slice.
@randall77
Copy link
Contributor

I have a CL related to this: https://go-review.googlesource.com/c/go/+/151497/
It's buggy somehow - I haven't dug back in to what the issue was.

Presumably the whole [3]interface{} type, including algorithms, is dead-code eliminated when linking.

@martisch
Copy link
Contributor

I was also noticing this and was looking into this for go1.13 and had made an issue related to this as the hash and eq is on the backing array #28639.

Also for performance which also improves the size for the non deadcode eliminated algs:
https://go-review.googlesource.com/c/go/+/148177

@bcmills bcmills added ToolSpeed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 28, 2019
@bcmills bcmills added this to the Go1.13 milestone Feb 28, 2019
@dsnet dsnet mentioned this issue Mar 1, 2019
Open
@dsnet
Copy link
Member

dsnet commented Mar 1, 2019

I just filed #30528 as a more generalized version of this problem. I imagine that its harder to resolve than this one here since it requires a wider-scope static analysis to prove certain facts.

@go101 go101 mentioned this issue Mar 2, 2019
Closed
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
binary-size compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. ToolSpeed
Projects
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Backlog
Development

No branches or pull requests
8 participants
@neild @rsc @martisch @andybons @bcmills @dsnet @randall77 @gopherbot