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

Projects
None yet
5 participants
@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

This comment has been minimized.

Copy link
Contributor

randall77 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

martisch 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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.