HTML をファイル システムに書き込む必要があり、File.WriteAllText() (または同様のテキスト メソッド) を使用するのではなく、HTML をバイトに変換して FileStream を使用して書き込むことで速度が向上するかどうか疑問に思っていました。
3 に答える
File.WriteAllText 内で何が起こると思いますか? 最終的には、ディスクにヒットするバイトになります。とにかく、そのディスクがこのチェーンの遅い部分である可能性は低くありません。書き込まれるデータが非常に大きい場合を除き、私はそれを気にせず、最も便利だと感じた実装を使用します。コードを適切に設計すれば、後で必要に応じて変更する大きな問題にはなりません。
最も読みやすく保守しやすいコードを最初に記述します。その後、パフォーマンスの問題が発生した場合は、ボトルネックを探します。
(ボトルネックが文字列をバイト配列に変換するかどうかに関係していることが判明した場合、私は非常に驚くでしょう。このようなボトルネックは、ディスクの書き込み速度になります)
File.WriteAllTextは、舞台裏でStreamWriterを使用します。
public static void WriteAllText(string path, string contents, Encoding encoding)
{
using (StreamWriter writer = new StreamWriter(path, false, encoding))
{
writer.Write(contents);
}
}
すでに文字列があります。これは、基になるEncoderクラスを使用してStreamWriter.Flushメソッド内で実行されるため、バイト配列に変換しても意味がありません。Flushは、using句が呼び出すStreamWriter.Disposeメソッドによって呼び出されます。これは、リフレクターを介したフラッシュのソースからのスニペットです。
int count = this.encoder.GetBytes(this.charBuffer, 0, this.charPos, this.byteBuffer, 0, flushEncoder);
あなたはそれがcharBufferを持っているのを見ることができます。これは、 StreamWriter.Write(string)を実行するときに書き込むchar[]配列にすぎません。
つまり、すでに文字列があります。短いFileメソッドにカスケード呼び出しを実行させるだけで、ソースが少し読みやすくなります。StreamWriterが自動的に行うので、バイト配列に変換する必要もありません。
変換の問題が発生した場合は、 File.WriteAllText(string、string)がBOMなしでUTF8を使用するため、3つのパラメーターのオーバーロードの最後のパラメーターとしてEncoding.Unicodeを使用します。