@rsc @RLH @randall77

I've calculated an optimistic approximation of the potential win by counting runtime.writebarrier calls right after runtime.newobject calls w/o any intervening calls in godoc binary.
Total number of writebarrier calls = 9732
writebarrier calls right after newobject = 2495
= ~25%

I'm not sure the gain is as large as you imply with your 25% number. If the
write barrier is off then the compiler will eventually emit a normal path
of a load of gcphase, a compare, and a branch. Since the branch is
predictable any reasonable OOO machine will do a pretty good job hiding the
sequence. It will be great when we get to a point where these types of
performance optimizations are at the top of our list for increasing
performance.

On Mon, Feb 2, 2015 at 12:23 PM, Dmitry Vyukov notifications@github.com
wrote:

I've calculated an optimistic approximation of the potential win by
counting runtime.writebarrier calls right after runtime.newobject calls w/o
any intervening calls in godoc binary.
Total number of writebarrier calls = 9732
writebarrier calls right after newobject = 2495
= ~25%

—
Reply to this email directly or view it on GitHub
#9755 (comment).

The compiler now emits the needWriteBarrier check. I think that's enough for Go 1.5. We can revisit this if and when profiles show that we're spending too much time on things like this.

This is fixed now; the following code has no write barriers:

package main

type X struct {
	p *int
	q []int
}

var obj int

func f(n int) {
	x := &X{&obj, make([]int, n)}
	g(x)
}

//go:noescape
func g(x *X)