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

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

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

Comments

@neild
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 28, 2019

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

@dsnet

This comment has been minimized.

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.