C ++標準では、iostreamのパフォーマンスの低下が義務付けられていますか？それとも、貧弱な実装を扱っているだけですか？

C ++標準ライブラリのiostreamのパフォーマンスが遅いことに言及するたびに、信じられないような波に遭遇します。それでも、iostreamライブラリコード（コンパイラの完全な最適化）に費やされた大量の時間を示すプロファイラー結果があり、iostreamからOS固有のI / O APIおよびカスタムバッファー管理に切り替えると、桁違いに改善されます。

C ++標準ライブラリはどのような追加の作業を行っていますか、それは標準で必要とされていますか、それは実際に役立ちますか？あるいは、一部のコンパイラーは、手動バッファー管理と競合するiostreamの実装を提供していますか？

ベンチマーク

問題を解決するために、iostreamの内部バッファリングを実行する短いプログラムをいくつか作成しました。

• バイナリデータをostringstream http://ideone.com/2PPYwに配置する
• バイナリデータをchar[]バッファに入れるhttp://ideone.com/Ni5ct
• http://ideone.com/Mj2Fivector<char>を使用してバイナリデータをback_inserter
• NEW：vector<char>シンプルなイテレーターhttp://ideone.com/9iitv
• NEW：バイナリデータをhttp://ideone.com/qc9QAに直接配置stringbuf
• NEW：vector<char>単純なイテレーターと境界チェックhttp://ideone.com/YyrKy

ostringstreamとstringbufバージョンは、実行速度が非常に遅いため、実行される反復が少ないことに注意してください。

ideoneに、ostringstreamよりも約3倍遅いstd:copy+ back_inserter+ std::vector、および約15倍より遅いmemcpy生バッファへ。これは、実際のアプリケーションをカスタムバッファリングに切り替えたときのプロファイリング前後のプロファイルと一致しています。

これらはすべてメモリ内バッファーであるため、iostreamの速度が遅いディスクI / O、過度のフラッシュ、stdioとの同期、またはC ++標準ライブラリーの観察された速度の遅さを弁解するために使用するその他のものに起因するものではありません。 iostream。

他のシステムのベンチマークや、一般的な実装（gccのlibc ++、Visual C ++、Intel C ++など）が行うこと、および標準によってどの程度のオーバーヘッドが義務付けられているかについての解説を見るとよいでしょう。

このテストの根拠

多くの人々は、フォーマットされた出力にはiostreamがより一般的に使用されていると正しく指摘しています。ただし、これらは、バイナリファイルアクセス用のC ++標準によって提供される唯一の最新のAPIでもあります。しかし、内部バッファリングでパフォーマンステストを実行する本当の理由は、一般的なフォーマット済みI / Oに当てはまります：iostreamがディスクコントローラーにrawデータを供給できない場合、フォーマットを担当しているときに、どのようにして対応できるでしょうか？

ベンチマークのタイミング

これらはすべて、外側の（k）ループの反復ごとです。

ideone（gcc-4.3.4、不明なOSおよびハードウェア）：

• ostringstream：53ミリ秒
• stringbuf：27ミリ秒
• vector<char>およびback_inserter：17.6ミリ秒
• vector<char> 通常のイテレータの場合：10.6 ms
• vector<char> イテレータと境界チェック：11.4 ms
• char[]：3.7ミリ秒

私のラップトップ（Visual C ++ 2010 x86 、、、cl /Ox /EHscWindows 7 Ultimate 64ビット、Intel Core i7、8 GB RAM）：

• ostringstream：73.4ミリ秒、71.6ミリ秒
• stringbuf：21.7 ms、21.3 ms
• vector<char>およびback_inserter：34.6 ms、34.4 ms
• vector<char> 通常のイテレータの場合：1.10 ms、1.04 ms
• vector<char> イテレータと境界チェック：1.11 ms、0.87 ms、1.12 ms、0.89 ms、1.02 ms、1.14 ms
• char[]：1.48 ms、1.57 ms

プロファイルに基づく最適化を使用してVisual C ++ 2010のx86、 、cl /Ox /EHsc /GL /c、link /ltcg:pgi実行、link /ltcg:pgo、対策：

• ostringstream：61.2 ms、60.5 ms
• vector<char> 通常のイテレータの場合：1.04 ms、1.03 ms

同じラップトップ、同じOS、cygwin gcc 4.3.4を使用g++ -O3：

• ostringstream：62.7 ms、60.5 ms
• stringbuf：44.4 ms、44.5 ms
• vector<char>およびback_inserter：13.5 ms、13.6 ms
• vector<char> 通常のイテレータの場合：4.1 ms、3.9 ms
• vector<char> イテレータと境界チェック：4.0 ms、4.0 ms
• char[]：3.57 ms、3.75 ms

同じラップトップ、Visual C ++ 2008 SP1 cl /Ox /EHsc：

• ostringstream：88.7 ms、87.6 ms
• stringbuf：23.3 ms、23.4 ms
• vector<char>およびback_inserter：26.1 ms、24.5 ms
• vector<char> 通常のイテレータの場合：3.13 ms、2.48 ms
• vector<char> イテレータと境界チェック：2.97 ms、2.53 ms
• char[]：1.52 ms、1.25 ms

同じラップトップ、Visual C ++ 2010 64ビットコンパイラ：

• ostringstream：48.6 ms、45.0 ms
• stringbuf：16.2 ms、16.0 ms
• vector<char>およびback_inserter：26.3 ms、26.5 ms
• vector<char> 通常のイテレータの場合：0.87 ms、0.89 ms
• vector<char> イテレータと境界チェック：0.99 ms、0.99 ms
• char[]：1.25 ms、1.24 ms

編集：2回すべて実行して、結果の一貫性を確認します。かなり一貫したIMO。

注：私のラップトップでは、ideoneが許可するよりも多くのCPU時間を節約できるため、すべてのメソッドの反復回数を1000に設定しました。この手段ostringstreamとvectorだけ最初のパスで行われます再配分は、最終的な結果にはほとんど影響を持っている必要があります。

編集：おっと、vector-with-ordinary-iteratorにバグが見つかりました。イテレータは高度ではなかったため、キャッシュヒットが多すぎました。私はどのようvector<char>に優れているか疑問に思っていましたchar[]。ただし、それほど大きな違いはありませんでしたが、VC ++ 2010 vector<char>よりも高速ですchar[]。

結論

出力ストリームのバッファリングには、データが追加されるたびに3つのステップが必要です。

• 入力ブロックが利用可能なバッファスペースに適合することを確認します。
• 入力ブロックをコピーします。
• データ終了ポインタを更新します。

私が投稿した最新のコードスニペット「vector<char>単純なイテレータと境界チェック」は、これを行うだけでなく、追加のスペースを割り当て、受信ブロックが収まらない場合に既存のデータを移動します。クリフォードが指摘したように、ファイルI / Oクラスでのバッファリングはそれを行う必要はなく、現在のバッファーをフラッシュして再利用するだけです。したがって、これは出力をバッファリングするコストの上限になるはずです。そして、それはメモリ内バッファを機能させるために必要なことです。

では、stringbufideoneでは2.5倍遅く、テストすると少なくとも10倍遅くなるのはなぜですか。この単純なマイクロベンチマークでは多態的に使用されていないため、説明はありません。

タイトルほど質問の詳細に答えない：C ++パフォーマンスに関する 2006年テクニカルレポートには、IOStreams（p.68）に関する興味深いセクションがあります。あなたの質問に最も関連するのは、セクション6.1.2（「実行速度」）です。

IOStreams処理の特定の側面は複数のファセットに分散されているため、標準では非効率的な実装が義務付けられているようです。しかし、そうではありません。何らかの前処理を使用することで、作業の多くを回避できます。通常使用されるよりも少しスマートなリンカーを使用すると、これらの非効率の一部を取り除くことができます。これについては、§6.2.3および§6.2.5で説明します。

このレポートは2006年に作成されたため、推奨事項の多くが現在のコンパイラに組み込まれていることを期待していますが、おそらくそうではありません。

あなたが言及するように、ファセットは機能しないかもしれませんwrite()（しかし、私はそれを盲目的に想定しません）。それでは何が特徴ですか？ostringstreamGCCでコンパイルされたコードでGProfを実行すると、次の内訳が得られます。

• 44.23％で std::basic_streambuf<char>::xsputn(char const*, int)
• 34.62％で std::ostream::write(char const*, int)
• 12.50％で main
• 6.73％で std::ostream::sentry::sentry(std::ostream&)
• 0.96％で std::string::_M_replace_safe(unsigned int, unsigned int, char const*, unsigned int)
• 0.96％で std::basic_ostringstream<char>::basic_ostringstream(std::_Ios_Openmode)
• 0.00％ std::fpos<int>::fpos(long long)

したがって、時間の大部分はで費やされxsputn、最終的にはstd::copy()、カーソル位置とバッファーの多数のチェックと更新の後に呼び出されます（c++\bits\streambuf.tcc詳細を確認してください）。

これについての私の見方は、あなたは最悪の状況に焦点を当ててきたということです。適度に大きなデータのチャンクを扱っている場合、実行されるすべてのチェックは、行われる作業全体のごく一部です。しかし、コードは一度に4バイトでデータをシフトし、毎回すべての追加コストが発生します。明らかに、実際の状況ではそうすることを避けwriteます。1つのintで1m回ではなく、1m intの配列で呼び出された場合のペナルティが無視できる程度であることを考慮してください。そして、実際の状況では、IOStreamsの重要な機能、つまりそのメモリセーフおよびタイプセーフデザインに本当に感謝します。このような利点には代償が伴い、これらのコストが実行時間を支配するようにするテストを作成しました。

私は、Visual Studioのユーザーにかなりがっかりしています。

• のVisual Studio実装でostreamは、sentryオブジェクト（標準でstreambuf必要）が（必須ではない）を保護するクリティカルセクションに入ります。これはオプションのようには見えないため、同期の必要がない単一のスレッドによって使用されるローカルストリームの場合でも、スレッド同期のコストを負担します。

これはostringstream、メッセージのフォーマットに使用するコードをかなりひどく傷つけます。をstringbuf直接使用するとsentry、の使用が回避されますが、フォーマットされた挿入演算子はで直接機能しませんstreambuf。Visual C ++ 2010の場合、クリティカルセクションはostringstream::write、基になるstringbuf::sputn呼び出しに対して3倍遅くなります。

newlibでbeldazのプロファイラーデータを見ると、gcc sentryはこのように奇妙なことを何もしていないことが明らかなようです。 ostringstream::writegccの下では、の約50％しかかかりませんがstringbuf::sputn、それstringbuf自体はVC ++の下よりもはるかに遅くなります。また、vector<char>VC ++と同じマージンではありませんが、どちらもI / Oバッファリングにforを使用する場合と比べて非常に好ましくありません。

表示される問題は、すべてwrite（）の呼び出しに関するオーバーヘッドにあります。追加する抽象化の各レベル（char []-> vector-> string-> ostringstream）は、関数呼び出し/戻り、および他のハウスキーピングガフをいくつか追加します。

ideoneの例を2つ変更して、一度に10整数を記述しました。ostringstreamの時間は53から6ミリ秒（ほぼ10倍の改善）になりましたが、charループは改善されました（3.7から1.5）-有用ですが、2倍にすぎません。

パフォーマンスが気になる場合は、ジョブに適したツールを選択する必要があります。ostringstreamは便利で柔軟性がありますが、意図したとおりに使用するとペナルティがあります。char []は難しい作業ですが、パフォーマンスが大幅に向上する可能性があります（gccはおそらくmemcpysもインライン化することを忘れないでください）。

要するに、ostringstreamは壊れていませんが、金属に近づくほどコードの実行が速くなります。アセンブラは、一部の人にとってはまだ利点があります。

パフォーマンスを向上させるには、使用しているコンテナがどのように機能するかを理解する必要があります。char []配列の例では、必要なサイズの配列が事前に割り当てられています。vectorとostringstreamの例では、オブジェクトが大きくなるにつれて、オブジェクトに繰り返し割り当てと再割り当てを強制し、データを何度もコピーします。

std :: vectorを使用すると、char配列のようにベクターのサイズを最終的なサイズに初期化することで簡単に解決できます。代わりに、サイズをゼロに変更することで、パフォーマンスを不当に低下させます。それは公平な比較ではありません。

ostringstreamに関しては、スペースを事前に割り当てることはできません。これは不適切な使用であることをお勧めします。クラスのユーティリティは単純なchar配列よりもはるかに優れていますが、そのユーティリティが必要ない場合は使用しないでください。いずれにしてもオーバーヘッドが発生するためです。代わりに、データを文字列にフォーマットするために使用する必要があります。C ++は幅広いコンテナーを提供しており、ostringstramはこの目的に最も適していないものの1つです。

vectorとostringstreamの場合、バッファーオーバーランから保護されますが、char配列では保護されません。その保護は無料ではありません。