System.IOの新しい特徴と機能改善

作者 Jonathan Allen , 翻訳者 徳武 聡 投稿日 2009年10月16日

セクション

設計/アーキテクチャ,

デベロップメント

トピック

.NETフレームワーク ,

.NET ,

プログラミング ,

パフォーマンス&スケーラビリティ

共有 |

原文(投稿日：2009/10/13)へのリンク

MicrosoftはSystem.IOの中核機能に対して、単純だが歓迎すべき改善を計画している。改善の中には、テキストファイルの読み取りと書き込みをする便利なメソッドや、ディレクトリ列挙の性能改善、メモリマップドファイルのサポートが含まれている。

まず、File.ReadAllLinesという便利なメソッドが、改善された別のメソッドに置き換わる。このメソッドは小さなサイズのファイルにとっては十分な機能を発揮するが、ファイルのサイズが大きくなると問題が発生する。根本的な問題はファイルの内容をすべて文字列の配列に読み込み終わるまで、プログラムの実行が停止してしまうことだ。

代わりになる新しいメソッドはFile.ReadLinesだ。このメソッドは文字列のenumeratorを返す。つまりこのメソッドを使えば、低レベルのストリームオブジェクトを扱っているときのように、ファイルを遅延読み込みすることができる。また、File.WriteAllLinesメソッドと File.AppendAllLinesメソッドの新しいオーバーロードも使えるようになる。両方とも、単純な配列ではなくenumeratorを引数にとる。

DirectoryInfo.GetFilesメソッドにも同じような配列の問題があるが、根底にはもっと深刻な問題が横たわっている。というのは、ファイルのリストを検索したとき、Win32 APIはファイルサイズや最終更新日時のような基本的な情報を.NET側に返しているが、.NET側はその情報をFileInfoオブジェクトの属性値として保持せずに、破棄してしまうのだ。そして、プログラムがFileInfoオブジェクトの配列の反復処理して、例えば、そのディレクトリにあるファイルのサイズの合計を算出しようとするとき、ひとつFileInfoオブジェクトを処理するごとに、もう一度ファイルシステムからファイルサイズを取得しなければならない。その結果、古典的な1+N最適化問題に行き着いてしまう。新しい DirectoryInfo.GetFilesメソッドと、DirectoryInfo.EnumerateFilesメソッドはこの問題を解決する。

その他の大きな改善といえば、.NETがメモリマップドファイルをサポートすることだ。メモリマップドファイルはオペレーティングシステムの機能で、ファイルにメモリブロックを割り当てる。一度割り当てれば、ファイルのどの部分でも任意に読んだり書いたりできる。単なるアンマネージメモリの配列にアクセスしているようにファイルを処理できるというわけだ。オペレーティングシステムはこの機能の重要な細部を扱っている。例えば、ファイルの異なった部分を必要に応じてメモリ上に読み込んだり、メモリ上から除いたりする処理だ。メモリマップドファイルを使えば、アプリケーションは信じられないほど大きなファイルでも処理できる。ギガバイトを超えていたとしても、効率的に扱うことができるだろう。

通常のファイルI/O処理に加えて、メモリマップドファイルはプロセス間での強力な通信方法を提供する。2つのアプリケーションが同じメモリマップドファイルを開いた場合、一方のアプリケーションが加えた変更は他方のアプリケーションへ即時に反映される。

またその名前に反して、メモリマップドファイルは実際のファイルでなくてもよい。補助記憶に存在しない純粋なメモリ上のオブジェクトであればいい。従ってアプリケーションからも利便性が高い機能だが、一方でプロセス間通信にも応用できるだろう。