I think this is a duplicate of a very similar issue I raised about 4-6
months ago.

On Tue, 26 Jul 2016, 07:34 Prashant Varanasi notifications@github.com
wrote:

Please answer these questions before submitting your issue. Thanks!

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

$ go version
go version go1.7rc3 darwin/amd64

(Also tested with go1.6.2)

What operating system and processor architecture are you using (go env
)?
darwin/amd64
2.

What did you do?
Create a simple struct User, and benchmark the difference between
&User{} and new(User):
https://github.com/prashantv/go-bench/blob/master/new_bench_test.go
3.

What did you expect to see?
Both to have the same performance and disassembly.
4.

What did you see instead?
new is consistently faster. Looking at the disassembly, new(User) does
less work than &User{}.

new does:

MOVQ BX, 0(SP)
CALL runtime.newobject(SB)
MOVQ 0x8(SP), CX
MOVQ 0x40(SP), AX

and then increments the counter and jumps to the if check.

&User{} is similar but then also stores a lot of 0s before jumping to the
if check:

MOVQ BX, 0(SP)
CALL runtime.newobject(SB)
MOVQ 0x8(SP), CX
XORL BP, BP
MOVQ BP, 0(CX)
MOVQ BP, 0x8(CX)
MOVQ BP, 0x10(CX)
MOVQ BP, 0x18(CX)
MOVQ BP, 0x20(CX)
MOVQ 0x40(SP), AX

It seems like &T{} is zeroing out the value even though runtime.newobject
already returns a zero'ed out object.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#16494, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcAyKc3f7BGHGxDG0MP-oLjncdGQ54ks5qZSvUgaJpZM4JUkkP
.

dupe of #15199 ?

That's the one, closing as dup.