List of Benchmark [text.Baldanders.info]

Go 1.24 からのベンチマークテスト

2025-03-15T12:08:09+00:00

現在『効率的なGo』の読書会に参加してるんだけど，今回はその10回目の話。

第67回横浜Go読書会（オンライン） - connpass

今回は「8章ベンチマーク」の最初の部分まで読み進めた。この辺からようやく Go のツールを使った具体的な話になってくる。

内容については本を読んでもらうとして，今回はベンチマーク・コードの話。件の本では「ほとんどのベンチマークに必要な小さなボイラープレートの生テンプレート」として以下のコードを挙げている。

func BenchmarkSum(b *testing.B) {
    b.ReportAllocs()
    // TODO(bwplotka): 必要な初期化処理を追加

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        // TODO(bwplotka): テストされた機能を追加
    }
}

『効率的なGo』リスト 8-1：Go のベンチマークの核となる要素より

ちなみに b.ReportAllocs() はヒープメモリの割り当て回数と総量をレポートするための関数で， go test -bench コマンドでベンチマークテストを起動する際の -benchmem オプションと同じ効果がある。

このコード中の for 文でカウンターを回しているのだが Go 1.24 から testing.B.Loop() メソッドが追加され for ループの記述が大きく改善された。

Benchmarks may now use the faster and less error-prone testing.B.Loop method to perform benchmark iterations like for b.Loop() { ... } in place of the typical loop structures involving b.N like for range b.N. This offers two significant advantages:

The benchmark function will execute exactly once per -count, so expensive setup and cleanup steps execute only once.

Function call parameters and results are kept alive, preventing the compiler from fully optimizing away the loop body.

via Go 1.24 Release Notes - The Go Programming Language

最初のほうの「コストのかかるセットアップおよびクリーンアップ手順は1回だけ実行される」というのは分かりにくいが，実は testing.B.Loop() メソッドを使うと，先のテンプレートコードにある b.ResetTimer() を省略できて，純粋に for b.Loop() { ... } 内の処理だけ計測される。

もうひとつはもっと重要で for b.Loop() { ... } 内のコードは最適化されないことを保証するというものだ。たとえば

func Add(a, b int) int {
	return a + b
}

という関数のベンチマークを取ろうとして素朴に

for range b.N {
    _ = Add(1, 2)
}

なんてなコードを書いたら，最悪の場合，最適化でループ内の処理がまるごと無くなりかねない¹。 testing.B.Loop() メソッドを使うことでそうした事態を回避できるというわけだ。

お試しに何か書いてみよう²。まずはこんな関数を書いてみる。

package sample

func Sum(data []int) int {
	total := 0
	for _, value := range data {
		total += value
	}
	return total
}

よくある合計値を返す関数ですな。作成した sample.Sum() 関数のベンチマークテストのコードは以下の通り。

package sample_test

import (
	"math/rand/v2"
	"sample"
	"testing"
)

func intList(n int) []int {
	list := make([]int, n)
	for i := range list {
		list[i] = rand.Int()
	}
	return list
}

func BenchmarkSum(b *testing.B) {
	b.ReportAllocs()
	input := intList(128 << 10)

	for b.Loop() {
		sample.Sum(input)
	}
}

さっそく実行してみよう³。

$ go test -run '^$' -bench '^BenchmarkSum$' -count 6 | tee sample_sum_bench_v1.txt
goos: linux
goarch: amd64
pkg: sample
cpu: AMD Ryzen 5 PRO 4650G with Radeon Graphics
BenchmarkSum-12        37249         32302 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        36802         32570 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        36495         34515 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        36825         32516 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        37101         32142 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        37298         32072 ns/op           0 B/op          0 allocs/op
PASS
ok      sample	7.260s

ヒープの使用もカウントされてないし，上手くいってるっぽいな。

もうひとつ。『効率的なGo』では benchstat コマンドの紹介もされていた。上のベンチマーク結果について簡単な統計処理をしてくれるらしい。これも試してみよう。

まずはコマンドのインストール。

$ go install golang.org/x/perf/cmd/benchstat@latest

先程のベンチマーク結果を benchstat コマンドに食わせてみる。

$ benchstat sample_sum_bench_v1.txt
goos: linux
goarch: amd64
pkg: sample
cpu: AMD Ryzen 5 PRO 4650G with Radeon Graphics
       │ sample_sum_bench_v1.txt │
       │         sec/op          │
Sum-12               32.41µ ± 6%

       │ sample_sum_bench_v1.txt │
       │          B/op           │
Sum-12                0.000 ± 0%

       │ sample_sum_bench_v1.txt │
       │        allocs/op        │
Sum-12                0.000 ± 0%

んー。 $6\,\%$ の分散はちょっと大きいかなぁ。『効率的なGo』によると，分散が $5\,\%$ 以上ある場合は環境ノイズ（バックグラウンドのプロセスとかメモリスワップとか）が大きい可能性があるらしい。まぁ，今回はこのまま進めよう。

benchstat で統計処理を行う場合は -count オプションを使って少なくとも6回以上は繰り返すべきと書かれている。これによって環境ノイズを検出しやすくなる。

benchstat コマンドは複数のベンチマーク結果を比較することもできる。

たとえば，先ほどの Sum() 関数のループ回数を半分にしたら速くなるだろうか。試してみよう。まず Sum() 関数を以下のように書き直す（ほとんど GitHub Copilot が書いたけどw）。

func Sum(data []int) int {
	total := 0
	l := len(data)
	h := l / 2
	for i := range h {
		total += data[i] + data[l-i-1]
	}
	if h*2 != l {
		total += data[h]
	}
	return total
}

これに対して先ほどと同じ条件でベンチマークテストを行う。

$ go test -run '^$' -bench '^BenchmarkSum$' -count 6 | tee sample_sum_bench_v2.txt
goos: linux
goarch: amd64
pkg: sample
cpu: AMD Ryzen 5 PRO 4650G with Radeon Graphics
BenchmarkSum-12    	   30920	     39051 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30186	     39492 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30282	     39615 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30373	     39535 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30525	     39413 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30379	     39540 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	sample	7.215s

ありゃ。さっきより遅くなっちゃった？ benchstat コマンドで確認してみよう。

$ benchstat sample_sum_bench_v1.txt sample_sum_bench_v2.txt
goos: linux
goarch: amd64
pkg: sample
cpu: AMD Ryzen 5 PRO 4650G with Radeon Graphics
       │ sample_sum_bench_v1.txt │      sample_sum_bench_v2.txt       │
       │         sec/op          │   sec/op     vs base               │
Sum-12               32.41µ ± 6%   39.51µ ± 1%  +21.92% (p=0.002 n=6)

       │ sample_sum_bench_v1.txt │    sample_sum_bench_v2.txt    │
       │          B/op           │    B/op     vs base           │
Sum-12                0.000 ± 0%   0.000 ± 0%  ~ (p=1.000 n=6) ¹
¹ all samples are equal

       │ sample_sum_bench_v1.txt │    sample_sum_bench_v2.txt    │
       │        allocs/op        │ allocs/op   vs base           │
Sum-12                0.000 ± 0%   0.000 ± 0%  ~ (p=1.000 n=6) ¹
¹ all samples are equal

$22\,\%$ 近く遅くなっちゃったよ orz

p の値は統計的有意性を表す $p\,値$のことで，既定では $\alpha=0.05$ に設定されている（$\alpha$ の値は -alpha オプションで変更できる）。つまり p の値が 0.05 より小さければ有意な値であると見なすことができる。

それはともかく，とりあえずループ回数を畳み込むのはなしの方向で。

…てな感じで benchstat コマンドを使えば統計学や誤差論の知識がなくてもある程度の判断を下すことができる。

ブックマーク

More predictable benchmarking with testing.B.Loop - The Go Programming Language

参考図書

効率的なGo ―データ指向によるGoアプリケーションの性能最適化: Bartłomiej Płotka (著), 山口能迪 (翻訳); オライリー・ジャパン 2024-02-24; 単行本（ソフトカバー）; 4814400535 (ASIN), 9784814400539 (EAN), 4814400535 (ISBN); 評価

版元で Ebook を買える。Go言語のリファレンス本ではない。フトウェア工学，プログラミング（の考え方）を学ぶ教科書的な位置づけかなぁ。

reviewed by Spiegel on 2024-04-21 (powered by PA-APIv5)

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

読書会のために購入。インプレス社の本は Kindle 版より版元で PDF 版を買うのがオススメ。「並行処理」について原理的な解説から丁寧に書かれている。 Go で解説されているが Go 以外の言語でも応用できる。

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

版元で PDF 版を購入可能。事実上の Effective Go とも言える充実の内容。オリジナルは敢えてタイトルに “tips” という単語を入れるのを避けたのに邦題が「100 Tips」とかなっていて，原作者がお怒りとの噂（あくまで噂）

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

実際に試してみたが10億回ループしてたので，やはり中身が消えてると思われる。ちなみにループ部分を for b.Loop() { ... } にしたら6億回のループになったので，多分そういうことなんだろう。 ↩︎
今回の記事のコードは testing パッケージのドキュメントにあるサンプルコードを参考にしている。 ↩︎
-run '^$' オプションはひとつもテストを実行しないことを示す。 -bench '^BenchmarkSum$' オプションは指定したベンチマークテストコードを実行することを示す。 -count 6 は指定したベンチマークテストを6回繰り返すことを示す。ベンチマークテストを繰り返すのは統計処理を行うため。 ↩︎

バイト列の同値性（『プログラミング言語 Go』読書会より）

2020-10-03T10:27:34+00:00

「第5回『プログラミング言語Go』オンライン読書会」に参加してみたです。

以前 Discord で某エベントに参加したことがあったけど，やっぱオンラインイベントはしんどい。それでもメインで喋る人が決まってるから，今回は楽なほうだったかな。 Discord にしろ Zoom にしろ，オンラインでフリートーク・イベントはかなり難しいと思うのだが，みんなどうしてるんだろう。

閑話休題 (それはさておき) 。

今回，のっけから面白い話を聞いた。『プログラミング言語 Go』4.2章「スライス」に書かれている

配列と異なりスライスは比較可能ではありませんので，二つのスライスが同じ要素で構成されているかを検査するために == は使えません。標準ライブラリは二つのバイトスライス（[]byte）を比較するために高度に最適化された bytes.Equal 関数を提供しています。しかし…

プログラミング言語 Goより

という部分（強調は私がやりました）。実際にコードを見てみると

// Equal reports whether a and b
// are the same length and contain the same bytes.
// A nil argument is equivalent to an empty slice.
func Equal(a, b []byte) bool {
	// Neither cmd/compile nor gccgo allocates for these string conversions.
	return string(a) == string(b)
}

てなことになっている。で，「これのどこが『高度に最適化』なん？」という話があったらしい。

バージョンを遡ってみると 1.12.7 までは

// Equal returns a boolean reporting whether a and b
// are the same length and contain the same bytes.
// A nil argument is equivalent to an empty slice.
func Equal(a, b []byte) bool {
	return bytealg.Equal(a, b)
}

となっていた。ちなみに internal/bytealg は内部パッケージで，中身はほぼ（アーキテクチャ毎に）アセンブラで記述されている。実は Go 1.13 では string 周りが大幅に強化されていて，その辺の影響が出ているのかもしれない。

それなら，どの程度のパフォーマンスか気になるよね。というわけで，こんなコードを用意してみた¹。

package eq

import (
	"bytes"
	"fmt"
	"testing"
)

var (
	hello1  = "I could tell you my pass phrase, but then I would have to kill you."
	hello2  = "I could tell you my pass phrase, but then I would have to kill you."
	helloA1 = [67]byte{0x49, 0x20, 0x63, 0x6f, 0x75, 0x6c, 0x64, 0x20, 0x74, 0x65, 0x6c, 0x6c, 0x20, 0x79, 0x6f, 0x75, 0x20, 0x6d, 0x79, 0x20, 0x70, 0x61, 0x73, 0x73, 0x20, 0x70, 0x68, 0x72, 0x61, 0x73, 0x65, 0x2c, 0x20, 0x62, 0x75, 0x74, 0x20, 0x74, 0x68, 0x65, 0x6e, 0x20, 0x49, 0x20, 0x77, 0x6f, 0x75, 0x6c, 0x64, 0x20, 0x68, 0x61, 0x76, 0x65, 0x20, 0x74, 0x6f, 0x20, 0x6b, 0x69, 0x6c, 0x6c, 0x20, 0x79, 0x6f, 0x75, 0x2e}
	helloA2 = [67]byte{0x49, 0x20, 0x63, 0x6f, 0x75, 0x6c, 0x64, 0x20, 0x74, 0x65, 0x6c, 0x6c, 0x20, 0x79, 0x6f, 0x75, 0x20, 0x6d, 0x79, 0x20, 0x70, 0x61, 0x73, 0x73, 0x20, 0x70, 0x68, 0x72, 0x61, 0x73, 0x65, 0x2c, 0x20, 0x62, 0x75, 0x74, 0x20, 0x74, 0x68, 0x65, 0x6e, 0x20, 0x49, 0x20, 0x77, 0x6f, 0x75, 0x6c, 0x64, 0x20, 0x68, 0x61, 0x76, 0x65, 0x20, 0x74, 0x6f, 0x20, 0x6b, 0x69, 0x6c, 0x6c, 0x20, 0x79, 0x6f, 0x75, 0x2e}
	helloS1 = []byte{0x49, 0x20, 0x63, 0x6f, 0x75, 0x6c, 0x64, 0x20, 0x74, 0x65, 0x6c, 0x6c, 0x20, 0x79, 0x6f, 0x75, 0x20, 0x6d, 0x79, 0x20, 0x70, 0x61, 0x73, 0x73, 0x20, 0x70, 0x68, 0x72, 0x61, 0x73, 0x65, 0x2c, 0x20, 0x62, 0x75, 0x74, 0x20, 0x74, 0x68, 0x65, 0x6e, 0x20, 0x49, 0x20, 0x77, 0x6f, 0x75, 0x6c, 0x64, 0x20, 0x68, 0x61, 0x76, 0x65, 0x20, 0x74, 0x6f, 0x20, 0x6b, 0x69, 0x6c, 0x6c, 0x20, 0x79, 0x6f, 0x75, 0x2e}
	helloS2 = []byte{0x49, 0x20, 0x63, 0x6f, 0x75, 0x6c, 0x64, 0x20, 0x74, 0x65, 0x6c, 0x6c, 0x20, 0x79, 0x6f, 0x75, 0x20, 0x6d, 0x79, 0x20, 0x70, 0x61, 0x73, 0x73, 0x20, 0x70, 0x68, 0x72, 0x61, 0x73, 0x65, 0x2c, 0x20, 0x62, 0x75, 0x74, 0x20, 0x74, 0x68, 0x65, 0x6e, 0x20, 0x49, 0x20, 0x77, 0x6f, 0x75, 0x6c, 0x64, 0x20, 0x68, 0x61, 0x76, 0x65, 0x20, 0x74, 0x6f, 0x20, 0x6b, 0x69, 0x6c, 0x6c, 0x20, 0x79, 0x6f, 0x75, 0x2e}
)

func BenchmarkByteEqual1(b *testing.B) {
	for i := 0; i < b.N; i++ {
		if hello1 != hello2 {
			fmt.Printf("false")
		}
	}
}

func BenchmarkByteEqual2(b *testing.B) {
	for i := 0; i < b.N; i++ {
		if !bytes.Equal([]byte(hello1), []byte(hello2)) {
			fmt.Printf("false")
		}
	}
}

func BenchmarkByteEqual3(b *testing.B) {
	for i := 0; i < b.N; i++ {
		if helloA1 != helloA2 {
			fmt.Printf("false")
		}
	}
}

func BenchmarkByteEqual4(b *testing.B) {
	for i := 0; i < b.N; i++ {
		if string(helloA1[:]) != string(helloA2[:]) {
			fmt.Printf("false")
		}
	}
}

func BenchmarkByteEqual5(b *testing.B) {
	for i := 0; i < b.N; i++ {
		if !bytes.Equal(helloA1[:], helloA2[:]) {
			fmt.Printf("false")
		}
	}
}

func BenchmarkByteEqual6(b *testing.B) {
	for i := 0; i < b.N; i++ {
		if string(helloS1) != string(helloS2) {
			fmt.Printf("false")
		}
	}
}

func BenchmarkByteEqual7(b *testing.B) {
	for i := 0; i < b.N; i++ {
		if !bytes.Equal(helloS1, helloS2) {
			fmt.Printf("false")
		}
	}
}

hello1, hello2 は string 型，helloA1, helloA2 は byte 配列，helloS1, helloS2 は []byte 型で中身はみんな同じ。これらを使って同値性（equallity）をチェックするのだが，内訳はこんな感じ。

関数名	比較手順
`BenchmarkByteEqual1`	`string == string`
`BenchmarkByteEqual2`	`bytes.Equal([]byte(string), []byte(string))`
`BenchmarkByteEqual3`	`<byte array> == <byte array>`
`BenchmarkByteEqual4`	`string(<array>[:]) == string(<array>[:])`
`BenchmarkByteEqual5`	`bytes.Equal(<array>[:], <array>[:])`
`BenchmarkByteEqual6`	`string([]byte) == string([]byte)`
`BenchmarkByteEqual7`	`bytes.Equal([]byte, []byte)`

では，実際に動かしてみようか。

$ go test -bench ByteEqual -benchmem
goos: linux
goarch: amd64
pkg: sample
BenchmarkByteEqual1-4   	301173402	         4.04 ns/op	       0 B/op	       0 allocs/op
BenchmarkByteEqual2-4   	 8552673	       122 ns/op	     160 B/op	       2 allocs/op
BenchmarkByteEqual3-4   	182939372	         6.27 ns/op	       0 B/op	       0 allocs/op
BenchmarkByteEqual4-4   	191359716	         6.29 ns/op	       0 B/op	       0 allocs/op
BenchmarkByteEqual5-4   	191511163	         6.27 ns/op	       0 B/op	       0 allocs/op
BenchmarkByteEqual6-4   	168382664	         7.16 ns/op	       0 B/op	       0 allocs/op
BenchmarkByteEqual7-4   	167058468	         7.06 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	sample	12.140s

分かりやすく表にしておく。ちなみに私の環境では 1ns 未満は誤差の範囲なのであしからず。

比較手順	処理時間 (ns/op)	Alloc 回数
`string == string`	4.04	0
`bytes.Equal([]byte(string), []byte(string))`	122.00	2
`<byte array> == <byte array>`	6.27	0
`string(<array>[:]) == string(array>[:])`	6.29	0
`bytes.Equal(array>[:], <array>[:])`	6.27	0
`string([]byte) == string([]byte)`	7.16	0
`bytes.Equal([]byte, []byte)`	7.06	0

string → []byte へのキャスト時にアロケーションが発生している点に注意。

つか string 同士の比較処理が速いな！配列と slice で若干差が出るのは仕方ないが，元が同じ型なら殆ど差がないようだ。まぁ，これなら確かに

func Equal(a, b []byte) bool { return string(a) == string(b) }

でもいっか，って気になるよな。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

ちなみに “I could tell you my pass phrase, but then I would have to kill you.” という物騒なフレーズは Simson Garfinkel 氏の『PGP』に載っていたパスフレーズの事例である（笑） ↩︎

strings.EqualFold 関数を使え

2019-12-15T09:01:19+00:00

GolangCI が吐くレビュー結果を基にチマチマとコードを直していたのだが，その中で

SA6005: should use strings.EqualFold(a, b) instead of strings.ToLower(a) == strings.ToLower(b)

if strings.ToLower(left) == strings.ToLower(right) {

という指摘があった。いや，もの知らずでゴメンペコン。

strings.EqualFold() 関数ってなんじゃら？と思ってソースコードを見たら

// EqualFold reports whether s and t, interpreted as UTF-8 strings,
// are equal under Unicode case-folding.
func EqualFold(s, t string) bool {
    ...
}

と書かれている。

ふむふむ。では試してみよう。こんな感じのコードを書いて

package main

import (
	"fmt"
	"strings"
)

func main() {
	lefts := []string{"go", "ｇｏ"}
	rights := []string{"Go", "GO", "go", "Ｇｏ", "ＧＯ", "ｇｏ"}

	for _, left := range lefts {
		for _, right := range rights {
			fmt.Printf("%s == %s : %v\n", left, right, strings.EqualFold(left, right))
		}
	}
}

実行してみると

$ go run sample1.go 
go == Go : true
go == GO : true
go == go : true
go == Ｇｏ : false
go == ＧＯ : false
go == ｇｏ : false
ｇｏ == Go : false
ｇｏ == GO : false
ｇｏ == go : false
ｇｏ == Ｇｏ : true
ｇｏ == ＧＯ : true
ｇｏ == ｇｏ : true

ってな感じになった。全角と半角は区別してくれるらしい。 Unicode の文字種をきちんと判別しているということだ。

ちなみに strings.ToLower() 関数を使って

package main

import (
	"fmt"
	"strings"
)

func main() {
	lefts := []string{"go", "ｇｏ"}
	rights := []string{"Go", "GO", "go", "Ｇｏ", "ＧＯ", "ｇｏ"}

	for _, left := range lefts {
		for _, right := range rights {
			fmt.Printf("%s == %s : %v\n", left, right, (left == strings.ToLower(right)))
		}
	}
}

とやっても同じ結果になる。

strings.EqualFold() 関数と strings.ToLower() 関数でどっちが速いかなんてのは考えるまでもないのだが，いちおう試しておこう。こんな感じのコードでいいかな。

package equalfold

import (
	"strings"
	"testing"
)

var (
	lefts   = []string{"go", "ｇｏ"}
	rights  = []string{"Go", "GO", "go", "Ｇｏ", "ＧＯ", "ｇｏ"}
	rights2 = []string{"go", "go", "go", "ｇｏ", "ｇｏ", "ｇｏ"}
)

func BenchmarkEqualCase(b *testing.B) {
	for i := 0; i < b.N; i++ {
		for _, left := range lefts {
			for _, right := range rights2 {
				if left == right {
					_ = left
				} else {
					_ = right
				}
			}
		}
	}
}

func BenchmarkEqualLower(b *testing.B) {
	for i := 0; i < b.N; i++ {
		for _, left := range lefts {
			for _, right := range rights {
				if left == strings.ToLower(right) {
					_ = left
				} else {
					_ = right
				}
			}
		}
	}
}

func BenchmarkEqualFold(b *testing.B) {
	for i := 0; i < b.N; i++ {
		for _, left := range lefts {
			for _, right := range rights {
				if strings.EqualFold(left, right) {
					_ = left
				} else {
					_ = right
				}
			}
		}
	}
}

BenchmarkEqualCase は他の2つのコードとの比較用に書いてみた。実行結果はこんな感じ。

$ go test -bench Equal -benchmem
goos: linux
goarch: amd64
pkg: sample
BenchmarkEqualCase-4    	32061360	        36.2 ns/op	       0 B/op	       0 allocs/op
BenchmarkEqualLower-4   	 1367802	       869 ns/op	      64 B/op	       8 allocs/op
BenchmarkEqualFold-4    	 3149362	       378 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	sample	4.748s

表にまとめておこう。

関数名	実行時間	Alloc サイズ	Alloc 回数
`BenchmarkEqualCase`	36.2 ns	0 bytes	0
`BenchmarkEqualLower`	869 ns	64 bytes	8
`BenchmarkEqualFold`	378 ns	0 bytes	0

BenchmarkEqualCase と BenchmarkEqualFold の比較では BenchmarkEqualFold のほうが10倍の時間がかかっているが，それよりも BenchmarkEqualLower の処理のほうが圧倒的に遅いことが分かる。まぁメモリ・アロケーションが絡むとねぇ。

というわけで，大文字小文字を無視した文字列比較では素直に strings.EqualFold() 関数を使いましょう，という話でした。

【付録】 “NUL” 文字の比較

まるきし余談ではあるが

Big Sky :: Go で大文字小文字無視の文字列比較ベンチマーク

この記事にある isDevNull3 関数について

func isDevNull3(name string) bool {
    return strings.ToLower(name) == "nul"
}

strings.EqualFold() 関数を使うよう書き換えてみる。

func isDevNull3(name string) bool {
	return strings.EqualFold(name, "nul")
}

これでベンチマークテストを実行すると

goos: linux
goarch: amd64
pkg: sample/lowercase
BenchmarkS1-4   	41640913	        27.2 ns/op	       0 B/op	       0 allocs/op
BenchmarkS2-4   	35464141	        30.7 ns/op	       0 B/op	       0 allocs/op
BenchmarkS3-4   	12628962	        94.4 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	sample/lowercase	3.578s

メモリ・アロケーションが発生しなくなり，かなり速くなる。まぁ，それでもいっちゃん遅いのだが（笑）

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

【改訂版】文字列連結はどれが速い？

2019-10-13T08:15:36+00:00

今回も小ネタでお送りしております。

2015年に「文字列連結はどれが速い？」という記事を書いた。あれから文字連結に関してどう変わったのか。特に Go 1.10 で strings.Builder が追加されているので，その辺も含めて再検証してみる。

今回検証するコードは以下の通り。

package join

import (
    "bytes"
    "strings"
)

var sz8k = 8 * 1024

func JoinStringPlus(ss []string) {
    var str string
    for _, s := range ss {
        str += s + "\n"
    }
}

func JoinStringJoin(ss []string) {
    strings.Join(ss, "\n")
}

func JoinStringByteAppend(ss []string) {
    b := []byte{}
    for _, s := range ss {
        b = append(b, s...)
        b = append(b, "\n"...)
    }
}

func JoinStringByteAppend8K(ss []string) {
    b := make([]byte, 0, sz8k)
    for _, s := range ss {
        b = append(b, s...)
        b = append(b, "\n"...)
    }
}

func JoinStringBuilder(ss []string) {
    b := &strings.Builder{}
    for _, s := range ss {
        b.WriteString(s)
        b.WriteString("\n")
    }
}

func JoinStringBuilder8K(ss []string) {
    b := &strings.Builder{}
    b.Grow(sz8k)
    for _, s := range ss {
        b.WriteString(s)
        b.WriteString("\n")
    }
}

func JoinStringBuffer(ss []string) {
    b := &bytes.Buffer{}
    for _, s := range ss {
        b.WriteString(s)
        b.WriteString("\n")
    }
}

func JoinStringBuffer8K(ss []string) {
    b := bytes.NewBuffer(make([]byte, 0, sz8k))
    for _, s := range ss {
        b.WriteString(s)
        b.WriteString("\n")
    }
}

各関数の内容は以下の通り。

関数名	内容
`JoinStringPlus`	`+` 演算子で連結する
`JoinStringJoin`	`strings.Join` 関数で連結する
`JoinStringByteAppend`	`[]byte` 配列に追記する
`JoinStringByteAppend8K`	`[]byte` 配列に追記する（8KB アロケーション）
`JoinStringBuilder`	`strings.Builder` に追記する
`JoinStringBuilder8K`	`strings.Builder` に追記する（8KB アロケーション）
`JoinStringBuffer`	`bytes.Buffer` に追記する
`JoinStringBuffer8K`	`bytes.Buffer` に追記する（8KB アロケーション）

使うメソッドによって出力する型が異なるが（string or []byte），今回は無視することにした¹。

ベンチマーク用のコードは以下の通り。

package join

import (
    "bufio"
    "os"
    "testing"
)

func ReadAll(path string) []string {
    file, err := os.Open(path) //maybe file path
    if err != nil {
        return nil
    }
    defer file.Close()

    scanner := bufio.NewScanner(file)
    list := []string{}
    for scanner.Scan() {
        list = append(list, scanner.Text())
    }
    if err := scanner.Err(); err != nil {
        return nil
    }
    return list
}

var content = ReadAll("CollisionsForHashFunctions.txt")

func BenchmarkJoinStringPlus(b *testing.B) {
    for i := 0; i < b.N; i++ {
        JoinStringPlus(content)
    }
}

func BenchmarkJoinStringJoin(b *testing.B) {
    for i := 0; i < b.N; i++ {
        JoinStringJoin(content)
    }
}

func BenchmarkJoinStringByteAppend(b *testing.B) {
    for i := 0; i < b.N; i++ {
        JoinStringByteAppend(content)
    }
}

func BenchmarkJoinStringByteAppend8K(b *testing.B) {
    for i := 0; i < b.N; i++ {
        JoinStringByteAppend8K(content)
    }
}

func BenchmarkJoinStringBuilder(b *testing.B) {
    for i := 0; i < b.N; i++ {
        JoinStringBuilder(content)
    }
}

func BenchmarkJoinStringBuilder8K(b *testing.B) {
    for i := 0; i < b.N; i++ {
        JoinStringBuilder8K(content)
    }
}

func BenchmarkJoinStringBuffer(b *testing.B) {
    for i := 0; i < b.N; i++ {
        JoinStringBuffer(content)
    }
}

func BenchmarkJoinStringBuffer8K(b *testing.B) {
    for i := 0; i < b.N; i++ {
        JoinStringBuffer8K(content)
    }
}

入力テキストは前回と同じ CollisionsForHashFunctions.txt を使用した。 8KB ほどのサイズがある。つまりコピー先バッファに 8KB の容量があれば追加のアロケーションは発生しないことになる。

では，さっそく実行してみる。

$ go test -bench JoinString -benchmem
goos: linux
goarch: amd64
pkg: join
BenchmarkJoinStringPlus-4                  19484         65256 ns/op      272160 B/op          69 allocs/op
BenchmarkJoinStringJoin-4                 371649          3087 ns/op        8192 B/op           1 allocs/op
BenchmarkJoinStringByteAppend-4           151417          8339 ns/op       35376 B/op          12 allocs/op
BenchmarkJoinStringByteAppend8K-4         502942          2544 ns/op        8192 B/op           1 allocs/op
BenchmarkJoinStringBuilder-4              130408          8434 ns/op       35376 B/op          12 allocs/op
BenchmarkJoinStringBuilder8K-4            418900          2781 ns/op        8192 B/op           1 allocs/op
BenchmarkJoinStringBuffer-4               133052          9545 ns/op       32240 B/op           8 allocs/op
BenchmarkJoinStringBuffer8K-4             351681          3526 ns/op        8192 B/op           1 allocs/op
PASS
ok      join    12.695s

結果を表にまとめておこう。

関数名	実行時間	Alloc サイズ	Alloc 回数
`JoinStringPlus`	65,256 ns	2,702,160 bytes	69
`JoinStringJoin`	3,087 ns	8,192 bytes	1
`JoinStringByteAppend`	8,339 ns	35,376 bytes	12
`JoinStringByteAppend8K`	2,544 ns	8192 bytes	1
`JoinStringBuilder`	8,434 ns	35,376 bytes	12
`JoinStringBuilder8K`	2,781 ns	8,192 bytes	1
`JoinStringBuffer`	9,545 ns	32,240 bytes	8
`JoinStringBuffer8K`	3,526 ns	8192 bytes	1

まず strings.Join() 関数を使った連結がめっさ速くなってアロケーション回数も1回のみになっていることにビックリした。ソースコードを見てみたら，やっぱり strings.Join() 関数内部で strings.Builder を使っていた。

// Join concatenates the elements of a to create a single string. The separator string
// sep is placed between elements in the resulting string.
func Join(a []string, sep string) string {
    switch len(a) {
    case 0:
        return ""
    case 1:
        return a[0]
    }
    n := len(sep) * (len(a) - 1)
    for i := 0; i < len(a); i++ {
        n += len(a[i])
    }

    var b Builder
    b.Grow(n)
    b.WriteString(a[0])
    for _, s := range a[1:] {
        b.WriteString(sep)
        b.WriteString(s)
    }
    return b.String()
}

ちなみに strings.Builder への追記処理は以下のようになっている。

// WriteString appends the contents of s to b's buffer.
// It returns the length of s and a nil error.
func (b *Builder) WriteString(s string) (int, error) {
    b.copyCheck()
    b.buf = append(b.buf, s...)
    return len(s), nil
}

つまり []byte 配列への append() と strings.Builder への追記と strings.Join() は実質的に同じ処理で，それぞれの前処理分だけ差が出ているということになる。

今回の検証では

やっぱり + 演算子による連結はダメダメ²
よほどの最適化が要求されない限り []byte 配列への append() は strings.Builder へ代替可能³
strings.Join() 関数のパフォーマンスは十分なので気軽に使ってよい
文字列連結に限るなら，もはや bytes.Buffer は有利とは言えない

といったところだろうか。

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

string 型は不変オブジェクトなので，通常は []byte 型との相互変換の際にメモリ・アロケーションとデータ・コピーが発生する。ちなみに strings.Builder の String() メソッドでは unsafe パッケージを使って無理やりキャスティングしている。 ↩︎
リテラル文字列同士の連結はコンパイラが処理するので + 演算子で無問題。 ↩︎
内部で append() 関数を使っていることから分かる通り strings.Builder のインスタンスはコピーして使えないので注意が必要である（インスタンスのポインタを渡せばOK）。当然ながら goroutine-safe ではないので複数の goroutine 間で共有できない。 ↩︎

テスト・フレームワークで Project Euler を解く

2018-03-26T10:27:50+00:00

別のセクションで「Project Euler で遊ぶ」話を書いたのだが，この記事のコメントで「ユニットテストを書く練習になる」というのがあって「なるほど！」と膝を打った。つか，自力で気づけよ，自分。まだまだ TDD が身につかないなぁ。

ちうわけで，以下の問題（Problem）をテスト・フレームワークで解いてみる。

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000.

via Problem 1 - Project Euler

10未満の自然数のうち, 3 もしくは 5 の倍数になっているものは 3, 5, 6, 9 の4つがあり, これらの合計は 23 になる.
同じようにして, 1000 未満の 3 か 5 の倍数になっている数字の合計を求めよ.

Problem 1 - PukiWikiより

まず，ベタに解いたコード。

//Answer0 returns answer to this problem
func Answer0(max int) int {
    sum := 0
    for n := 1; n < max; n++ {
        if (n%3) == 0 || (n%5) == 0 {
            sum += n
        }
    }
    return sum
}

これをテストにかける。

package problem1

import "testing"

func TestAnswer(t *testing.T) {
    testCases := []struct {
        max, answer int
    }{
        {max: 10, answer: 23},
    }

    for _, tc := range testCases {
        a := Answer0(tc.max)
        if a != tc.answer {
            t.Errorf("Answer0(%v) = %v, want %v.", tc.max, a, tc.answer)
        }
    }
}

実行すると以下の通り。

$ go test -v .
=== RUN   TestAnswer
--- PASS: TestAnswer (0.00s)
PASS
ok      project-euler/problem-1   0.128s

これで最初の例示について正しい答えを出していることがわかる。では1,000未満についてもやってみようか。以下のようにテスト項目を追加する。

func TestAnswer(t * testing.T) {
    testCases := []struct {
        max, answer int
    }{
        {max: 10, answer: 23},
        {max: 1000, answer: 0},
    }

    for _ , tc := range testCases {
        a := Answer0(tc.max)
        if a != tc.answer {
            t.Errorf("Answer0(%v) = %v, want %v.", tc.max, a, tc.answer)
        }
    }
}

まだ正解が分からないので，とりあえず 0 をぶちこんでいる。これを実行する。

$ go test -v .
=== RUN   TestAnswer
--- FAIL: TestAnswer (0.00s)
        answer_test.go:16: Answer0(1000) = ******, want 0.
FAIL
FAIL    project-euler/problem-1   0.106s
exit status 1

テストは当然失敗するが，回答が表示されるので¹ これを Project Euler のサイトで入力してチェックする。正解が分かったら改めて正解をテストにセットしなおす。

func TestAnswer(t * testing.T) {
    testCases := []struct {
        max, answer int
    }{
        {max: 10, answer: 23},
        {max: 1000, answer: ******},
    }

    for _ , tc := range testCases {
        a := Answer0(tc.max)
        if a != tc.answer {
            t.Errorf("Answer0(%v) = %v, want %v.", tc.max, a, tc.answer)
        }
    }
}

これで再テストすると

$ go test -v .
=== RUN   TestAnswer
--- PASS: TestAnswer (0.00s)
PASS
ok      project-euler/problem-1   0.128s

ちゃんと PASS していることが確認できた。

改良版

ここで解説を参考に改良版のコードを組む。こんな感じ。

//Answer1 returns answer to this problem (refactoring version)
func Answer1(max int) int {
    return sumDivisibleBy(max, 3) + sumDivisibleBy(max, 5) - sumDivisibleBy(max, 3*5)
}

func sumDivisibleBy(max, n int) int {
    m := (max - 1) / n
    return n * (m * (m + 1)) / 2
}

このコードも同じテストにかける。

func TestAnswer(t * testing.T) {
    testCases := []struct {
        max, answer int
    }{
        {max: 10, answer: 23},
        {max: 1000, answer: ******},
    }

    for _ , tc := range testCases {
        a := Answer0(tc.max)
        if a != tc.answer {
            t.Errorf("Answer0(%v) = %v, want %v.", tc.max, a, tc.answer)
        }
        a = Answer1(tc.max)
        if a != tc.answer {
            t.Errorf("Answer1(%v) = %v, want %v.", tc.max, a, tc.answer)
        }
    }
}

全てのテストケースでパスすればOK。

ベンチマーク・テスト

更に Answer0(), Answer1() 両関数をベンチマーク・テストで比較してみることにする。ベンチマーク・テスト用のコードは以下の通り²。

func BenchmarkAnswer0(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = Answer0(1000)
    }
}

func BenchmarkAnswer1(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = Answer1(1000)
    }
}

ではベンチマーク・テストを実行してみる。

$ go test -bench . -benchmem
goos: windows
goarch: amd64
pkg: project-euler/problem-1
BenchmarkAnswer0-4        500000              2415 ns/op               0 B/op          0 allocs/op
BenchmarkAnswer1-4      2000000000               0.29 ns/op            0 B/op          0 allocs/op
PASS
ok      project-euler/problem-1   1.952s

おおっ。万倍ちがうぜ（笑）

このようにテストフレームワークを使って楽しく Project Euler で遊ぶことができる。テストを書く習慣づけになればもっといいんだろうけど。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

一応ネタバレ防止用に伏字にしている。ご容赦。 ↩︎
ベンチマーク用のコードは ***_test.go ファイルに含めること。また関数名は Benchmark から始まる名前にする。 ↩︎

「ズンドコチェック」なるものが流行っているらしい

2016-03-12T13:12:53+00:00

Javaの講義、試験が「自作関数を作り記述しなさい」って問題だったから
「ズン」「ドコ」のいずれかをランダムで出力し続けて「ズン」「ズン」「ズン」「ズン」「ドコ」の配列が出たら「キ・ヨ・シ！」って出力した後終了って関数作ったら満点で単位貰ってた
— てくも (@kumiromilk) 2016年3月9日

「習作（study）」としてはなかなか秀逸なアイデアだと思う。これで満点くれる教官も流石だが（笑）巷では「ズンドコキヨシ」とか「キヨシチェック」とか「ズンドコチェック」とか呼ばれているらしい。

というわけで

「ズン」「ドコ」のいずれかをランダムで出力し続けて「ズン」「ズン」「ズン」「ズン」「ドコ」の配列が出たら「キ・ヨ・シ！」って出力した後終了って関数

を Go 言語で実装することを考えてみる。私はコレを「ズンドコ・コール（zundoko-choir）」と呼ぶことにする。

とはいえ，ズンドコ・コールを実装する事自体はそう難しくない。たとえばこんな感じ。

package main

import (
    "fmt"
    "math/rand"
    "time"
)

const (
    zun     = "ズン"
    doko    = "ドコ"
    kiyoshi = "キ・ヨ・シ！"
)

func generate() chan string {
    ch := make(chan string)
    go func() {
        var zundoko = [2]string{zun, doko}
        rand.Seed(time.Now().UnixNano())
        for {
            ch <- zundoko[rand.Intn(2)]
        }
    }()
    return ch
}

func main() {
    zundoko := generate()
    zcount := 0
    for {
        zd := <-zundoko
        fmt.Print(zd)
        if zd == zun {
            zcount++
        } else if zcount >= 4 {
            break
        } else {
            zcount = 0
        }
    }
    fmt.Print(kiyoshi)
}

「ズン」および「ドコ」をランダムに生成する部分は channel と goroutine を使えばいいだろう（generate() 関数内の処理）。擬似乱数は厳密でなくてもいいので安直に math/rand を使うことにした¹。さらに「ズン」「ズン」「ズン」「ズン」「ドコ」の配列パターンのチェックだが，「ズン」が4回以上連続で来た直後に「ドコ」が来たら OK としてみた。まぁ，これがもっとも素朴な実装でパフォーマンスとしてもそれほど遜色ない筈。

と，ここまで考えてハタと気づいた。問題は「自作関数を作り記述しなさい」なんだからメイン関数にロジック書いたらアカンやん！

というわけでまたもゴリゴリとコードを書いてパッケージにしてしまった。アホだ，私（笑）

spiegel-im-spiegel/zundoko: Zundoko-choirs

出力は標準出力に直書きするのではなく string の slice に append() することで実現する。この出力先を Choirs 型として定義した。

//Choirs - zundoko-choirs list
type Choirs struct {
    c []string
}

//Push is append choirs
func (c *Choirs) Push(s string) {
    c.c = append(c.c, s) //maybe panic if c is nil.
}

func (c *Choirs) String() string {
    if c == nil {
        return ""
    }
    content := make([]byte, 0, 128)
    for _, s := range c.c {
        content = append(content, s...)
    }
    return string(content)
}

ちなみに文字列の連結は strings.Join() 関数は使わず「文字列連結はどれが速い？」で紹介した方法を使っている。

これで最初のコードは

func generate() chan string {
    ch := make(chan string)
    go func() {
        var zd = [2]string{Zun, Doko}
        rand.Seed(time.Now().UnixNano())
        for {
            ch <- zd[rand.Intn(2)]
        }
    }()
    return ch
}

//Run zundoko-choirs
func Run() *Choirs {
    zd := generate()
    c := &Choirs{make([]string, 0)}
    zcount := 0
    for {
        s := <-zd
        c.Push(s)
        if s == Zun {
            zcount++
        } else if zcount >= 4 {
            break
        } else {
            zcount = 0
        }
    }
    c.Push(Kiyoshi)
    return c
}

と書き換えることができる。このパッケージを呼び出すメイン側は例えば

package main

import (
    "fmt"

    "github.com/spiegel-im-spiegel/zundoko"
)

func main() {
    c := zundoko.Run()
    fmt.Println(c)
}

と書けばいい。

ところで「ズン」「ドコ」の出力は Choirs 型で保持られているので，末尾の5要素のパターンを調べる別の方法もあると気づく。たとえばこんな感じ。

var matchingPattern = []string{Zun, Zun, Zun, Zun, Doko}

func (c *Choirs) match() bool {
    if c == nil {
        return false
    }
    if len(c.c) < 5 {
        return false
    }
    return reflect.DeepEqual(c.c[len(c.c)-5:], matchingPattern)
}

この関数を使えば Run() 関数は

//Run2 zundoko-choirs (another logic)
func Run2() *Choirs {
    zd := generate()
    c := &Choirs{make([]string, 0)}
    for {
        s := <-zd
        c.Push(s)
        if c.match() {
            break
        }
    }
    c.Push(Kiyoshi)
    return c
}

となり随分すっきりする。ただこれコストが高くつきそうである。というわけで，これも調べてみた。まず以下のベンチマークを書く。

package zundoko

import "testing"

func BenchmarkRun1(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Run()
    }
}

func BenchmarkRun2(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Run2()
    }
}

BenchmarkRun1 が従来のもの， BenchmarkRun2 が先程の match() 関数を使ったバージョンである。結果は以下のとおり。

$ go test -bench Run -benchmem
testing: warning: no tests to run
PASS
BenchmarkRun1-4    50000     28141 ns/op    1800 B/op     9 allocs/op
BenchmarkRun2-4    30000     40102 ns/op    3912 B/op   115 allocs/op
ok      github.com/spiegel-im-spiegel/zundoko   4.261s

乱数の要素が絡むので毎回同じ値ではないが，傾向としてはこんな感じ。 BenchmarkRun2 のほうが allocation 回数が圧倒的に多いのが分かるだろう。これがスピードにもダイレクトに反映されている感じである。

今回は「「ズン」が4回以上連続で来た直後に「ドコ」が来たら OK」という単純なロジックだったが，もっと複雑なパターンが要求される場合は工夫が必要かもしれない²。

「ズン」と「ドコ」の出現回数を数える関数も作ってみた。

//CountZunDoko returns count of "ZUN" and "DOKO" choirs
func (c *Choirs) CountZunDoko() (int, int) {
    z := 0
    d := 0
    if c == nil {
        return z, d
    }
    for _, s := range c.c {
        switch s {
        case Zun:
            z++
        case Doko:
            d++
        }
    }
    return z, d
}

たとえば generate() 関数内で使っている擬似乱数パッケージを別のものに換えた時に統計処理で簡単な性能評価ができるかもしれない。今回はそこまではしなけど（擬似乱数の話はいずれやりたい）。

こうやって手遊びでコードを弄るのは楽しいものである。

ブックマーク

ズンドコキヨシまとめ - Qiita
ズンドコキヨシ with Go (n番煎じ) - Qiita
ズンドコキヨシGolang並列版 - Qiita : 「ズン」「ドコ」の生成部分を CPU の数だけ並列処理で行わせてひとつの channel に入力するというユニークな実装
「ズンドコキヨシ」と擬似乱数 - Qiita : Qiita で擬似乱数について簡単にまとめてみた。整理できたらこちらでも記事にするかも

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

math/rand の乱数生成アルゴリズムの既定は線形合同法らしい。線形合同法は性能が良くなくゲームや暗号等では使えない。math/rand の乱数生成アルゴリズムは他のものに入れ替えることができる。たとえば seehuhn/mt19937 パッケージが使える。 ↩︎
たとえば container/list や container/ring といったパッケージを使う手がある。 ↩︎

文字列連結はどれが速い？

2015-09-21T14:08:07+00:00

（初出： Golang の文字列連結はどちらが速い？ - Qiita）

前回につづき string の話題。 Go 言語で文字列の連結を行う際にどうやるのが一番速いか，という話。

【2019-10-13 追記】 改訂版を公開しました。

文字列連結を行う4つの方法

Go 言語で文字列の連結を行う際には概ね以下の4つの方法がある。

“+” 演算子で連結する
strings.Join で連結する
bytes.Buffer に追記する
[]byte に append する

string は「不変（immutable）」なので，最初の2つが高コストになるだろうことはすぐに想像がつく。

では残りの2つはどうなのかというと

Goの文字列結合のパフォーマンス - Qiita

によると最後のが一番速いらしい。ほんじゃまぁ，確かめてみるか。

サンプルコードを用意

以下のコード join.go を使って評価してみる。

package main

import (
    "bufio"
    "bytes"
    "io"
)

//Read content (text data) from buffer
func ContentText(inStream io.Reader) ([]string, error) {
    scanner := bufio.NewScanner(inStream)
    list := make([]string, 0)
    for scanner.Scan() {
        list = append(list, scanner.Text())
    }
    if err := scanner.Err(); err != nil {
        return nil, err
    }
    return list, nil
}

//Write content (text data) to buffer
func WriteBuffer1(lines []string) []byte {
    //write to byte buffer
    content := make([]byte, 0)
    recode := "\r\n"
    for _, line := range lines {
        content = append(content, line...)
        content = append(content, recode...)
    }
    return content
}

//Write content (text data) to buffer
func WriteBuffer1Cap128(lines []string) []byte {
    //write to byte buffer
    content := make([]byte, 0, 128) //128 bytes capacity
    recode := "\r\n"
    for _, line := range lines {
        content = append(content, line...)
        content = append(content, recode...)
    }
    return content
}

//Write content (text data) to buffer
func WriteBuffer1Cap1K(lines []string) []byte {
    //write to byte buffer
    content := make([]byte, 0, 1024) //1K bytes capacity
    recode := "\r\n"
    for _, line := range lines {
        content = append(content, line...)
        content = append(content, recode...)
    }
    return content
}

//Write content (text data) to buffer (buffered I/O)
func WriteBuffer2(lines []string) []byte {
    //write to byte buffer
    content := bytes.NewBuffer(make([]byte, 0))
    recode := "\r\n"
    for _, line := range lines {
        content.WriteString(line)
        content.WriteString(recode)
    }
    return content.Bytes()
}

//Write content (text data) to buffer (buffered I/O)
func WriteBuffer2Cap128(lines []string) []byte {
    //write to byte buffer
    content := bytes.NewBuffer(make([]byte, 0, 128)) //128 bytes capacity
    recode := "\r\n"
    for _, line := range lines {
        content.WriteString(line)
        content.WriteString(recode)
    }
    return content.Bytes()
}

//Write content (text data) to buffer (buffered I/O)
func WriteBuffer2Cap1K(lines []string) []byte {
    //write to byte buffer
    content := bytes.NewBuffer(make([]byte, 0, 1024)) //1K bytes capacity
    recode := "\r\n"
    for _, line := range lines {
        content.WriteString(line)
        content.WriteString(recode)
    }
    return content.Bytes()
}

テストコード join_test.go はこんな感じ。

package main

import (
    "os"
    "testing"
)

func readFile() []string {
    file, err := os.Open("CollisionsForHashFunctions.txt") //maybe file path
    if err != nil {
        panic(err)
    }
    defer file.Close()
    list, err := ContentText(file)
    if err != nil {
        panic(err)
    }
    return list
}

func BenchmarkWriteBuffer1(b *testing.B) {
    list := readFile()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        content := WriteBuffer1(list)
        _ = string(content)
    }
}

func BenchmarkWriteBuffer1Cap128(b *testing.B) {
    list := readFile()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        content := WriteBuffer1Cap128(list)
        _ = string(content)
    }
}

func BenchmarkWriteBuffer1Cap1K(b *testing.B) {
    list := readFile()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        content := WriteBuffer1Cap1K(list)
        _ = string(content)
    }
}

func BenchmarkWriteBuffer2(b *testing.B) {
    list := readFile()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        content := WriteBuffer2(list)
        _ = string(content)
    }
}

func BenchmarkWriteBuffer2Cap128(b *testing.B) {
    list := readFile()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        content := WriteBuffer2Cap128(list)
        _ = string(content)
    }
}

func BenchmarkWriteBuffer2Cap1K(b *testing.B) {
    list := readFile()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        content := WriteBuffer2Cap1K(list)
        _ = string(content)
    }
}

Go 言語のテストについては以前紹介したが，同じ要領で Benchmark から始まる名前の関数を作るとベンチマーク用のコードとして認識される。引数には b *testing.B を指定する。

ベンチマークの内訳は以下のとおり。

ベンチマーク名	処理内容
`BenchmarkWriteBuffer1`	`[]byte` に `append` する
`BenchmarkWriteBuffer1Cap128`	`[]byte` に `append` する（ capacity 128B）
`BenchmarkWriteBuffer1Cap1K`	`[]byte` に `append` する（ capacity 1KB）
`BenchmarkWriteBuffer2`	`bytes.Buffer` に追記する
`BenchmarkWriteBuffer2Cap128`	`bytes.Buffer` に追記する（ capacity 128B）
`BenchmarkWriteBuffer2Cap1K`	`bytes.Buffer` に追記する（ capacity 1KB）

入力テキストだが，小さいファイルではテストにならない気がしたので，大昔に書いたテキスト CollisionsForHashFunctions.txt を使うことにした。サイズは70行，7KB ほど。

テスト結果

結果は以下のとおり。

C:>go test -bench WriteBuffer -benchmem
testing: warning: no tests to run
PASS
BenchmarkWriteBuffer1-8           100000         17831 ns/op       37056 B/op     12 allocs/op
BenchmarkWriteBuffer1Cap128-8     100000         20321 ns/op       36992 B/op     11 allocs/op
BenchmarkWriteBuffer1Cap1K-8      100000         19301 ns/op       36096 B/op      8 allocs/op
BenchmarkWriteBuffer2-8           100000         17300 ns/op       33760 B/op     10 allocs/op
BenchmarkWriteBuffer2Cap128-8     100000         19451 ns/op       34992 B/op      9 allocs/op
BenchmarkWriteBuffer2Cap1K-8      100000         15490 ns/op       25712 B/op      6 allocs/op
ok      join    12.659s

ありゃりゃ。 bytes.Buffer を使ったほうが速いみたい（capacity を大きくとれば）。

それなら，入力テキストを切り詰めて10行，0.3KB にしてやってみる。

C:>go test -bench WriteBuffer -benchmem
testing: warning: no tests to run
PASS
BenchmarkWriteBuffer1-8          2000000           859 ns/op        1312 B/op      5 allocs/op
BenchmarkWriteBuffer1Cap128-8    2000000           707 ns/op        1248 B/op      4 allocs/op
BenchmarkWriteBuffer1Cap1K-8     2000000           796 ns/op        1376 B/op      2 allocs/op
BenchmarkWriteBuffer2-8          1000000          1686 ns/op        1600 B/op      6 allocs/op
BenchmarkWriteBuffer2Cap128-8    1000000          1411 ns/op        1680 B/op      5 allocs/op
BenchmarkWriteBuffer2Cap1K-8     2000000           980 ns/op        1488 B/op      3 allocs/op
ok      join    13.589s

今度は []byte の方が速くなった。

まぁでも予想通りかな。データのサイズが大きくなればバッファ操作のほうが有利になるのは分かりやすいっちゃあ分かりやすい。

注目すべきは BenchmarkWriteBuffer1Cap128 と BenchmarkWriteBuffer1Cap1K で， capacity を 1KB 取ったほうが若干遅くなっている。この辺のチューニングをどうするか，というところなのだろう（実はこれ，環境によって微妙に順位が変わるんだよなぁ）。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価