Go言語の構造体へのアクセス方法による効率の違い(ポインタor実体)

Question

Go言語における構造体のフィールドへのアクセス方法には、ドット(.)を使用した場合、次の二通りがあると思います。

type Node struct {
	id int
}

func main() {
	n := Node{}
	n.id = 0

	m := &Node{}
	m.id = 0
}

この二つの方法の性能を測るベンチマークを次のコードで実行しました。

package test

import (
	"testing"
)

type Node struct {
	id int
}

const C = 10000

func BenchmarkA(b *testing.B) {
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		n := Node{}
		n.id = 0
	}
}

func BenchmarkB(b *testing.B) {
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		n := &Node{}
		n.id = 0
	}
}

以下のような結果が出ました。数回計測しましたが、どれもほぼ同じ結果でした。(ns/opに0.01ほどの差)

$ go test -bench . -benchmem -gcflags '-N -l'
goos: linux
goarch: amd64
BenchmarkA-6    1000000000               0.993 ns/op           0 B/op          0 allocs/op
BenchmarkB-6    801381580                1.49 ns/op            0 B/op          0 allocs/op

実体からフィールドにアクセスする場合とポインタからアクセスする場合で、なぜ速度が変わるのでしょうか？

次に、構造体そのものをスライスにappendする場合と構造体のポインタをappendする場合の差を調べるために、以下のコードでベンチマークを行いました。

package test

import "testing"

type Node struct {
	id int
}

const C = 10000

func BenchmarkA(b *testing.B) {
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		l := []Node{}
		for j := 0; j < C; j++ {
			n := Node{}
			l = append(l, n)
		}
	}
}

func BenchmarkB(b *testing.B) {
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		l := []*Node{}
		for j := 0; j < C; j++ {
			n := &Node{}
			l = append(l, n)
		}
	}
}

結果は以下のようになりました。

$ go test -bench . -benchmem -gcflags '-N -l'
goos: linux
goarch: amd64
BenchmarkA-6       22455             53447 ns/op          386301 B/op         20 allocs/op
BenchmarkB-6        5648            192217 ns/op          466298 B/op      10020 allocs/op

ポインタをappendする方が、メモリ割り当て回数が非常に多くなっていて、実行時間も増えています。
どこでこのような差が生まれているのでしょうか？

Answer 1

単純にヒープメモリ操作回数がメモリ割り当て回数にそのまま出ています。

• 最初にスライスを確保した場合１回のメモリ割り当てが発生します
• スライスをゼロサイズからGrowさせていく場合、1,2,4,8...とスライスのメモリ拡張処理が発生します（この場合19回）
• A:Node{}はスタックに設けられたスペースに初期化されスライスが持つメモリにコピーされる
• B:&Node{}の結果をコンテナに投入する場合スタックは利用せずヒープからnew(Node)と等価処理します。(=10000回割り当て)

ベンチマークコードのlの初期値を以下の様に書くと、スライスのメモリ拡張処理がなくなります。

l := make([]Node, 0, C)

l := make([]*Node, 0, C)

結果の例

BenchmarkA-4   	   59569	     23897 ns/op	   81920 B/op	       1 allocs/op
BenchmarkB-4   	    3640	    304698 ns/op	  161920 B/op	   10001 allocs/op
PASS

ポインタ型をnewする以上、メモリ割り当てを回避するのは難しいです。
（Goのコンパイラがスタック割り当てで済むと判断した時だけスタックになります）

例示の状況であれば「非ポインタ型構造体」のほうが良いことだらけに見えます。ただ、スライスにappendする時にコピーするのは「ポインタ値のサイズ（CPUレジスタ１個分）」のみです。非ポインタ型構造体をスライスにappendする時にコピーするのは「構造体全体のサイズ」です。また、引数渡しや返値渡し、メソッドレシーバーアクセスのたびに「非ポインタ型構造体」は「構造体全体のコピー」が発生します。

つまり、構造体定義のサイズでトレードオフが発生します。あるていど構造体定義が肥大化すると利点の効果よりもコピーコストの方が問題として大きくなります。

また、インターフェース型として取り回す際、非ポインタ型の場合はいくらか制約が発生します。速度問題がクリティカルであると判断するまではほとんどのケースでポインタ型を使っておく方が無難ではあります。

僕の場合、「とりあえずポインタ型で実装ー＞GCで遅い問題がでたらsync.Poolなどで確保メモリの再利用を検討する」という流れが多いです。最初から非ポインタ構造体で設計するのはフィールド内容が定義上不変である場合に限ります（2D/3Dベクトルなど）。

Comments

[nobonobo]

メモリ再利用には再利用特有の課題もあるので注意が必要ですが。（初期化の責任が別途発生する）

[mask_mus]

前回に引き続きご回答いただきありがとうございます。
３つほど追加で質問があります。

・A:Node{}はスタックに設けられたスペースに初期化されスライスが持つメモリにコピーされる、についてですが、この場合、コピー先のスライスのメモリはスタックになるのでしょうかヒープになるのでしょうか？

・一つ目のベンチマークについてですが、ヒープの割り当てはどちらも行われていないように見えるのですが、速度の差はどこで生じるのでしょうか？

・非ポインタ構造体のレシーバとポインタ構造体のレシーバでは速度に差はあるのでしょうか？

[nobonobo]

ひとつめ：スタックに初期化されヒープにあるスライス用の配列メモリにコピーされます。
ふたつめ：短命なオブジェクトはスタックに置いても大丈夫という判断をコンパイラがそう判断します。
みっつめ：メソッドコールにはレシーバのコピーが発生します。レシーバがポインタ型ならポインタだけのコピーで済みます。

[mask_mus]

何度も質問してしまい申し訳ないのですが、
n:=Node{}
n.id=0
と
n:=&Node{}
n.id=0
のフィールドのアクセス方法に、性能的な違いはあるのでしょうか？

[nobonobo]

アセンブリコードは読めますか？極端な速度チューニングをするには必要になる知識です。
もし読めないならそちらの学習をしてみることをお勧めします。

go tool compile -S sample_test.go > asm.S

などとするとアセンブリコードが出力されます。こちらを読めばどちらがどう違うか大して差がないのかは一目瞭然です。

個人的には回答の後半に示した通りポインタ型でまずは組みましょう。
そして、実際のアプリケーションでプロファイルを録って、
最もクリティカルなところだけにチューニングを検討しましょう。