仕事であるプログラムを作成する事になりました。
Unityでマイクの音声をずーっと録音し続けてファイルに保存するというプログラムです。
今までだとそういう時は、バッファにずーっとデータを溜めていって、最後にファイル書き込みって処理にしてましたが、今回は下手すると１時間くらい録音する可能性があるそうです。
１時間分のwavファイルは600MBくらいあります。
数百MBだの1GBだのデータを素直にメモリに持ちたくありません。
なので音声データを随時にファイルにチビチビ書き込む事にしました。
しかし私はファイル操作の挙動について疎かったので、一応検証する事にしました。
メモリ
ここからよく分かってなかったのですが、調べたところでは、ファイルをオープンしただけならサイズが小さいファイルだろうがでかいファイルだろうがメモリは食いません。
次にStreamWriterでWriteしまくってるとメモリ消費量が増えるのか？というと、そんな事はありません。
StreamWriterはある程度書き込むデータが溜まってからまとめて書き込むので、そのバッファ分の数kBは消費しますが、それ以上はどんどんファイルに書き込むのでメモリは減りません。
実際ザックリ検証した感じでもWriteを何回やっても使用メモリ量は増えてませんでした。
速度
ファイルサイズが大きくなるにつれてStreamWriter.Writeが遅くなったりとかするのか？
これもわからなかったので検証してみました。
StopWatchクラスで計測しました。検証用コードはすいませんが面倒なので掲載しません。
ちなみに私のＰＣのディスクはHDDです。
１． ファイルを作成してクローズするだけを１回
平均約1ms
２． ファイルを作成して1万回write（”美樹さやかわ”という12byteデータ）してクローズ
平均約23ms
１回あたりのwriteのコストは0.002msほどでしょうか。ゲームで毎フレームちびちびWriteしてもさして問題なさそうです。
３． ファイルオープン、write、クローズを１万回
12,878ms
オープンクローズだけで1msだったので１万回なら当然１万倍で順当じゃないでしょうか。毎フレームファイルのクローズすべきか？というとコストがあるのでファイルは開きっぱなしの方が良さそうですね。毎フレ1msのコストはゲームとかでは無視できないです。
４． 176kBのファイルをオープンクローズだけ１万回
1,042ms
５． 1.76GBのファイルをオープンクローズだけ１万回
945ms
ファイルのオープンクローズはファイルサイズによって処理時間変わるのか？という検証ですが、変わらないみたいです。
６． 176MBずつファイルにWriteしていくのを１０回（最終的に1.76GBになる）
平均約600ms
ファイルサイズによってWriteの処理時間は変わるか？という検証ですが、特に有意に処理時間が増えたりはしませんでした。
７． 1.76GBのファイルを追記(Append)でオープンして１万回Writeしてクローズ
5ms
ファイルサイズが大きくてもWriteの処理速度のペナルティはあまりなさそうです。
８． 1.76GBのファイルを追記オープン、Write、クローズを１万回
33.645ms
これは３のケースに比べると３倍くらい処理速度が増えてます。ファイルサイズに比例するほどのペナルティは無いとはいえ、若干はあるのかも知れません。
まとめ
消費メモリと処理速度の観点から検証しましたが、やはりファイルオープンしっぱなしで毎フレームちょっとずつ音声データをWrite、最後にファイルクローズという手法で問題なさそうです。
今回は書き込みのケースだけで読み込み(StreamReader)については未検証ですが、要領としては同様（ちょっとずつファイルから読み出しがベスト）だと思われます。