2019-12-07

Golangのバッファってよくできてるよな

Golang

みんなのGoを読んでいて、バッファの取り扱いを理解できてないと感じたので簡単にまとめてみました。

info

この記事では chan のバッファリングについては取り扱いません。

バッファとは

そもそもバッファは何なのかといえば、なんらかの入出力の一部を一時的に保存する領域を指します。

この領域は、IOの回数を減らしてパフォーマンスを向上させますが、際限なく大きればいいというものでもありません。すべてを読み込んでしまうと大きなファイルの場合、メモリを圧迫する恐れがあります。

そこで一定のサイズの領域、(例えば4KB とする)を確保し4KBずつ読み出してバッファに格納＆コピー先のファイルに書き出す、という操作を繰り返せば最大でも4KBしか消費されないのでメモリを圧迫する恐れがありません。

逆に小さすぎれば大量のIOが発生しものすごい時間がかかるかもしれません。

バッファサイズは省メモリとパフォーマンスのトレードオフ関係にあると言えます。

info

通常のシステムではスペックに合わせて適切なバッファサイズを設定することが望ましいですが、当記事ではわかりやすさを考慮して小さなサイズのバッファを使うことがあります。

Go言語におけるバッファリング

`[]byte`

Golang におけるバッファは主にbyte型のスライス([]byte)で表現されます。 byte は 1バイトで表される 0 から255 の整数値を扱います。

バッファに対してIOから読み書きを行うんですが、ネットワークやファイルなどIOにもいくつか種類があります。 IOごとにバラバラの読み書き方法があるとめんどくさいのでGolangでは読み書きの方法(メソッド)がある程度統一されています。

info

この統一されたメソッドを変数に対して強制させるのがインタフェースです。
インタフェースにはメソッドにどのような引数を渡してどのような値が返却されるべきかが定義されており、インタフェース型変数に格納される値にメソッドが定義されていなければビルドが通らないようになっています。
入出力に関するインタフェースは ioパッケージに以下のように定義されており、利用者はインタフェースを見るだけでどのように呼び出せばいいかがわかります。

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

標準、準標準パッケージのIOをはじめ、多くのIOはこれらのインタフェースを満たすように設計されています。
だからこそ私達はインタフェースを使って抽象的なコードを書くことができます。
自分たちで IO を書く場合もこれらのインタフェースを満たすように設計すべきです。

第一引数のファイルを第二引数のファイルにコピーする(cpコマンドのような)プログラムを書いてみました。 5バイトのバッファを使って泥臭く読み書きを繰り返しているだけです。処理をわかりやすくするためにエラーハンドリングや後処理は書きませんでした。

$ cat read.txt
0123456789
abc

$ go run copy.go read.txt write.txt
01234 5
56789 5

abc
 5
 0

$ cat write.txt
0123456789
abc

重要なのはRead でバッファを受け取って、読み込んだバイト数を返しているところです。読み込んだバイト数が0なら処理を終了し、それ以外なら Write で切り出したバッファを書き込んでいます。バッファには前に読み込んだバイト列が残っているので切り出さないと予期せぬ内容が書き込まれてしまいます。

info

ちなみに、IOから際限なくすべての文字列を読み込みたい場合、 ioutil.ReadAllを使うと良いでしょう。
内部では後述する bytes.Buffer が使われています

bytes.Buffer

bytes 標準パッケージにはBuffer という構造体が定義されていて、これをバッファとして使うこともできます。内部にバッファとして byte のスライスを持ちます。

NewBuffer 関数を使うと初期バッファは利用者が指定できます。

type Buffer struct {
  buf      []byte // contents are the bytes buf[off : len(buf)]
  off      int    // read at &buf[off], write at &buf[len(buf)]
  lastRead readOp // last read operation, so that Unread* can work correctly.
}

フィールドは外部からアクセスできませんが、バッファを操作するためのメソッドが用意されています。

今回は gore というプログラムを利用して対話的に結果を見ていきます。

gore> :import bytes

// バイト列からバッファを作る
gore> b := bytes.NewBuffer([]byte("test"))
&bytes.Buffer{buf:[]uint8{0x74, 0x65, 0x73, 0x74}, off:0, lastRead:0}

// 中身
gore> b.String()
"test"

// キャパシティは4
gore> b.Cap()
4

// testなので4文字
gore> b.Len()
4

// 別のバッファを []byte で作成
gore> b2 = make([]byte, 10)
[]byte{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}

// b の内容を今作成したバッファに移す(Read)
gore> b.Read(b2)
4
<nil>

// b2の先頭4バイトに書き込まれている
gore> string(b2)
"test\x00\x00\x00\x00\x00\x00"

// 読まれたので seekが進んで
gore> b
&bytes.Buffer{buf:[]uint8{0x74, 0x65, 0x73, 0x74}, off:4, lastRead:-1}

// もう読み出せないらしい(Seek的なものはReaderにしかないっぽい)
gore> b.String()
""

// 仕方ないのでWriteで再度バッファを戻す(Write)
gore> b.Write([]byte("test"))
4
<nil>
gore> b
&bytes.Buffer{buf:[]uint8{0x74, 0x65, 0x73, 0x74}, off:0, lastRead:0}
gore> b.String()
"test"

// Reset で空っぽにできる Trancate(0) と同じ
gore> b.Reset()
gore> b
&bytes.Buffer{buf:[]uint8{}, off:0, lastRead:0}

bytes.Buffer 自体がバッファだと考えてしまうと Read, Write関連のメソッドって向きがさっきと逆じゃねーかと思ってしまいそうですが、これらはIOとして呼ばれることが前提となっているメソッドなので「引数であるバッファ」が主語になります。

具体的には以下の Fprintf のように引数でIOを指定する関数では bytes.Buffer はIOのように振る舞います。出力された値をバッファに格納できます。

gore> b = bytes.NewBuffer([]byte(""))
&bytes.Buffer{buf:[]uint8{}, off:0, lastRead:0}
gore> b.String()
""
gore> fmt.Fprintln(b, "test")
5
<nil>
gore> b.String()
"test\n"

Read, Write を使うと IOのように振る舞えるのはわかりましたが、先程のように別のIOの読み書きはどうやるんでしょうか。

ここで使うのが ReadFrom と WriteTo です。それぞれ、 io.Reader と io.Writer のインタフェースが引数となっているので、適切なIOを渡してやるだけです。

ファイルを読み込んで表示するだけのプログラムを作りました。例のごとくエラーハンドリングはしてません。

$ go run cat.go read.txt
0123456789
abc

この場合はバッファ(bytes.Buffer)が主語となり、読み込むときは ReadFrom を、書き込むときは WriteTo を使います。

info

ReadFrom は最低だと 512 バイトのバッファが使われます。
- https://github.com/golang/go/blob/dev.boringcrypto.go1.13/src/bytes/buffer.go#L193>
- もし読み込みが遅い場合、 Grow でバッファサイズを上げるか、 NewBuffer で大きなバッファを渡してあげましょう。
ここでいうキャパシティはスライスにとっての cap の意味であり、バッファへの書き込みを制限できるという意味のキャパシティではありません。
- キャパシティを超えて書き込まれれば自動的にアロケーションされます。
上述したように bytes.Buffer は書き込まれた内容を際限なく溜め込みます。
- バッファに入っている内容が不要になったら Reset や Trancate メソッドで削除しましょう。

bufio

bufio はIOをラップしてそこに対する入出力をバッファリングする標準パッケージです。 IOアクセス処理で透過的にバッファを利用します。

再びファイルを表示するためのプログラムを書いてみました。

$ go run cat2.go read.txt
0123456789
abc

結果は同じですが、bytes.Buffer を使ったコードより行数が増えています。何が嬉しいのでしょうか？

bytes.Buffer は内部のバッファに上限を持たないため、読み込んだものをすべてバッファに入れることが可能です。実際、先程のコードは一気に読み込んで一気に出力していた(かつエラーハンドリングもしてない)のであれだけ短くできました。

bufio の Reader と Writer はともにバッファに上限を持つため、バッファを超える入出力を考慮して繰り返し読み書きするプログラムを書く必要があります。正直めんどくさくはありますが、メモリが有限なことを考えればこちらのほうが現実的です。(バッファサイズは小さすぎますが)

バッファの書き込み

通常、IOへの書き込みでは自動的にバッファされないため、連続した読み書きを行うとパフォーマンス劣化を招く恐れがあります。

bufio.Writer への書き込みは「自身のバッファサイズの限界に達したとき」、あるいは「 Flush メソッドを実行したとき」に IOへの書き込みが発生するため、IOアクセスを抑えパフォーマンス向上につながります。

なにげに先程のプログラムでも bufio.Writerは使っていましたが、正直あれだけではありがたみがわからないので書き込み回数ごとに実行時間を計測するプログラムを書きました。

$ go test -bench Bench
goos: linux
goarch: amd64
BenchmarkWrite                          1000000000               0.00528 ns/op
BenchmarkWriteWithBufferOnceInTen       1000000000               0.00191 ns/op
BenchmarkWriteWithBuffer1K              1000000000               0.000145 ns/op
BenchmarkWriteWithBuffer4K              1000000000               0.000067 ns/op
PASS
ok      ./benchmark        0.056s

毎回書き込んでるのは一番遅く、書き込み回数が減るごとにパフォーマンスが向上しているのがわかります。

info

BenchmarkWriteWithBuffer はデフォルトのバッファサイズが一番大きいので最速のはずですが、結構ブレが大きくて1Kのバッファが一番速くなることもよくありました。(よくわからん)

bufio.Scanner

bufio.Scanner は1行ごとにテキストを読み込む機能です。

再び gore を使って動きを見てみましょう。

gore> :import strings
// 1文字ごとに改行を入れた4行のテキスト
gore> s := strings.NewReader("1\n2\n3\n4")
&strings.Reader{s:"1\n2\n3\n4", i:0, prevRune:-1}

gore> :import bufio
gore> scanner := bufio.NewScanner(s)
&bufio.Scanner{r:(*strings.Reader)(0xc00000c060), split:(bufio.SplitFunc)(0x48eda0), maxTokenSize:65536, token:[]uint8(nil), buf:[]uint8(nil), start:0, end:0, err:error(nil), empties:0, scanCalled:false, done:false}

// まだScanしてない状態でテキストを呼ぶとエラー
gore> s.Text()
s.Text undefined (type *strings.Reader has no field or method Text)
gore> scanner.Text()
""
gore> scanner.Scan()
true
gore> scanner.Text()
"1"
gore> scanner.Scan()
true
gore> scanner.Text()
"2"
gore> scanner.Scan()
true
gore> scanner.Text()
"3"
gore> scanner.Scan()
true
gore> scanner.Text()
"4"
gore> scanner.Scan()
false
gore> scanner.Text()
""
gore> scanner.Err()
<nil>

Scan メソッドを呼ぶと改行コードが見つかるまで文字列を読み込み Text メソッドで読み込んだ(改行コードを除いた)テキストを返却します。

Scan は読み込めたら true 読み込めなかったら false を返すため for 文の条件句で Scan を呼び出し、 forの中で Text メソッドを呼ぶのが一般的な使い方だと思います。

以下は標準入力から受け取った1行の文字列をそのまま返却するエコーサーバです。

$ go run echo.go
遊ぼう
遊ぼう
ばか
ばか
もう遊ばない
もう遊ばない
ごめんね
ごめんね
こだまでしょうか？
いいえ、だれでも

(ネタが古い)

一行あたりの最大バイト数は 64KB という制限があります。 Scan メソッドがエラーを返さないので気づきにくいですが、 scanner.Err() をちゃんと確認しましょう。

gore> s := strings.NewReader(strings.Repeat("a", 65536))
gore> scanner := bufio.NewScanner(s)
&bufio.Scanner{r:(*strings.Reader)(0xc00000c060), split:(bufio.SplitFunc)(0x48eda0), maxTokenSize:65536, token:[]uint8(nil), buf:[]uint8(nil), start:0, end:0, err:error(nil), empties:0, scanCalled:false, done:false}
gore> scanner.Scan()
false
gore> scanner.Err()
&errors.errorString{s:"bufio.Scanner: token too long"}

先程のコードを見ればわかると思いますが、長すぎて読み込めない場合は Scan() メソッドが false を返すため自動的にループを抜けます。

バイナリファイルや一行あたりの文字数が保証されないファイルでは bufio.Reader を使ってください。

考察

bytes.Buffer, bufio いずれを使っても同じ結果を得るプログラムを書けましたがそれぞれの性質は全く異なり、それに伴い使い所も違ったものになるでしょう。

bytes.Buffer は読み込まれた内容を自由に溜め込み、書き出す用途に適している
bufio は特定の IO に密接に結びつき、IOとバッファのデータ受け渡しをシンプルに書くのに適している

よくできてると言いましたが、 IOがインタフェースを満たすように設計された結果、バッファを扱う各関数は抽象化したコードになるのだと思います。

参考

【Go言語】bufio.Scannerの静かな突然死に3営業日ハマった - DRYな備忘録tl;dr bufio.ScannerでScanが終わってもErrはちゃんと見ましょう。以上。問題継続的に書き込みのあるTCP接続からの読み込みを、bufio.Scannerをつかって華麗に逐次読み込みしていた。が、どうやらそれが静かに切断され、クライアント（こちら）側のローカルでの処理が先走っているように見える挙動があった。 res, err := ExecRemoteLongScript() defer res.Body.Close() scanner := bufio.NewScanner(res.Body) for scanner.Scan() { // do something …https://otiai10.hatenablog.com/entry/2018/01/23/121058 Just a moment...https://medium.com/golangspec/introduction-to-bufio-package-in-golang-ad7d1877f762 Goのruneを理解するためのUnicode知識 - Qiitastring? byte? rune?最近LeetCodeというサイトにあるコーディング問題をGoでちまちま解き進めている。コーディング問題では普段はしないような処理を書くことがあるが、その中で…https://qiita.com/seihmd/items/4a878e7fa340d7963fee [Golang] ファイル読み込みサンプル - QiitaはじめにGolangのファイル読み込みをまとめました。バージョンは1.11.2で確認しました。os.File Read使用os.Openでファイルのオープンで取得したos.Fileオブジェクト…https://qiita.com/tchnkmr/items/b686adc4a7e144d48755 io package - io - Go Packageshttps://golang.org/pkg/io/