c# - System.IO.ReadAllxxx / WriteAllxxx メソッドのパフォーマンス

Question

Web で利用可能な System.IO.File.ReadAllxxx / WriteAllxxx メソッドと StreamReader / StremWriter クラスのパフォーマンス比較はありますか。.net 3.0 でテキストファイルを読み書きするための (パフォーマンスの観点から) 最善の方法は何だと思いますか?

System.IO.File class の MSDN ページを確認したところ、サンプルコードでは MS がファイル操作に StreamReader / StreamWriter を使用しています。File.ReadAllxxx / WriteAllxxx メソッドを避ける特定の理由はありますか?

score 5 · Accepted Answer

非常に大きなファイルのロード/保存をサポートする意図がある場合は、File.ReadAllxxx/WriteAllxxxを使用したくないでしょう。

つまり、ギガバイトサイズのファイルを編集するときに引き続き使用できるようにするエディターの場合、StreamReader / StreamWriterを使用してシークするデザインが必要になるため、ファイルの表示されている部分のみをロードします。

これらの（まれな）要件がない場合は、簡単なルートを使用してFile.ReadAllxxx/WriteAllxxxを使用します。akuが示すように、とにかく手動でコーディングするのと同じStreamReader/Writerパターンを内部で使用します。

score 4 · Accepted Answer

File.ReadAllText および同様のメソッドは内部で StreamReader/Writers を使用するため、パフォーマンスは自分で行うものと同等である必要があります。

可能な限り File.XXX メソッドを使用することをお勧めします。これにより、コードが a) 読みやすくなり、b) バグが含まれる可能性が低くなります (自分で作成した impl に)。

score 1 · Accepted Answer

テキストファイルに複数行の一致である正規表現を適用するなどのことをしていない限り、一般的に ReadAll/WriteAll は避けたいものです。扱いやすい小さなチャンクで処理を行うと、ほとんどの場合、パフォーマンスが向上します。

たとえば、データベースからテーブルを読み取り、それをクライアントの Web ブラウザーに送信することは、小さなネットワークメッセージの性質を利用して処理コンピューターのメモリの使用量を削減する小さなセットで実行する必要があります。10,000 レコードを Web サーバーのメモリにバッファリングして、一度にすべてダンプする理由はありません。ファイルシステムについても同じことが言えます。大量の少量のデータの書き込みパフォーマンス (基盤となるファイルシステムでスペースを割り当てるために何が起こっているか、オーバーヘッドは何かなど) に関心がある場合は、次の記事が参考になるかもしれません。

Windows ファイルキャッシュの使用状況

ファイル読み取りのベンチマーク

明確化: ReadAll に続いて String.Split('\r') を実行してファイル内のすべての行の配列を取得し、 for ループを使用して各行を処理している場合、そのコードは一般的に悪化します行ごとにファイルを読み取り、各行でプロセスを実行するよりもパフォーマンスが向上します。これは難しいルールではありません。かなりの時間を要する処理がある場合は、システムリソース (ファイルハンドル) をすぐに解放した方がよい場合がよくあります。ただし、ファイルの書き込みに関しては、ほとんどの場合、アイテムをメモリにバッファリングするよりも、アイテムごとに変換プロセス (アイテムの大きなリストで ToString() を呼び出すなど) の結果をダンプする方が適切です。

score 1 · Accepted Answer

このMSR (Microsoft Research) の論文は良い出発点です。また、IOSpeed、FragDisk など、環境で使用およびテストできる多数のポイントツールも文書化されています。

シーケンシャル IO を最大化する方法について読むことができる更新されたレポート/プレゼンテーションもあります。「HDヘッドの移動は最も時間がかかる操作である」という神話を暴く非常に興味深いものであり、テスト環境と関連する構成、マザーボード、RAIDコントローラー、およびそれらを複製するための事実上すべての再現情報に至るまで、完全に文書化しています。仕事。ハイライトのいくつかは、Opteron / XEON がどのように一致したかですが、測定のために非常識な誇大広告の NEC Itanium (32 または 64 プロセッサなど) と比較しました。ここの 2 番目のリンクから、ハイスループットのシナリオとニーズをテストおよび評価する方法に関するより多くのリソースを見つけることができます。

この同じ研究トピックの他の MSR 論文のいくつかには、使用パターンに対応するためにどこで支出を最大化するか (RAM、CPU、ディスクスピンダルなど) についてのガイダンスが含まれています。

ただし、一部は古くなっていますが、通常は古い API の方が高速で低レベルのものです ;)

私は現在、C#、C++/CLI、ネイティブコード、およびビットマップキャッシング (rtl*bitmap) を組み合わせて使用して、専用のアプリサーバーに何十万もの TPS をプッシュしています。

気をつけて;

score 0 · Accepted Answer

@FredrikKalsethは正しいです。File.ReadXXXメソッドは、StreamReaderクラスの便利なラッパーです。

たとえば、ここにFile.ReadAllTextの実装があります

public static string ReadAllText(string path, Encoding encoding)
{
    using (StreamReader reader = new StreamReader(path, encoding))
    {
        return reader.ReadToEnd();
    }
}

score 0 · Accepted Answer

このリンクには、50+K 行を読み取るためのベンチマークがあり、ストリームリーダーが約 40% 高速であることを示しています。

http://dotnetperls.com/Content/File-Handling.aspx

score 0 · Accepted Answer

パフォーマンスについては他の人が説明しているので追加はしませんが、ヘルパーメソッドが利用できなかった .NET 2.0 より前に MSDN コードサンプルが作成された可能性が高いことを付け加えておきます。

c# - System.IO.ReadAllxxx / WriteAllxxx メソッドのパフォーマンス

7 に答える 7

Related

Reference