c++ - シリアライゼーション コードのプロファイリング

Question

アプリを 2 回 (VS IDE で) 実行しました。初回は33秒かかりました。多くのコードを呼び出す obj.save のコメントを外しましたが、87 秒かかりました。それはいくつかの遅いシリアル化コードです! 私は2つの問題を疑っています。最初は私が以下を行うことです

template<class T> void Save_IntX(ostream& o, T v){ o.write((char*)&v,sizeof(T)); }

私はこのテンプレートを何十万回も呼び出しています (まあ、それほど多くはないかもしれません)。各 .write() は、速度を低下させている可能性のあるロックを使用していますか? たぶん、ロックを必要としないメモリストリームを使用して、代わりにダンプできますか? ロックされず、おそらく単一のスレッドでのみ使用されることに依存する、どのostreamを使用できますか?

もう 1 つの疑わしい問題は、dynamic_cast を多用していることです。しかし、これを回避できるかどうかはわかりません。

これは、ostream の代わりに fopen を使用するように変換した後の簡単なプロファイリング セッションです。このリストに自分の関数の大部分が表示されないのはなぜだろうと思いますが、ご覧のとおり、書き込みがまだ最も長くかかっています。注：出力ファイルが半分のギグであることを認識しています。おっとっと。多分それが理由です。

Answer 1

理解できてよかったですが、次にプロファイリングを行うときは、いくつかの点を考慮する必要があるかもしれません。

• サンプリング モードの VS プロファイラーは、I/O 中やプログラムがブロックされている間はサンプリングを行わないため、CPU バウンドのプロファイリングにのみ役立ちます。たとえば、ルーチンの包括時間が 80% であると表示されていても、アプリが実際に計算しているのは時間の 10% だけである場合、その 80% は実際にはわずか 8% です。このため、CPU バウンドでない作業では、プロファイラーの計測モードを使用する必要があります。

• それを行ったと仮定すると、これらすべてのデータ列の中で重要なのは「包括的 %」です。これは、回避できた場合に全体の時間がどれだけ削減されるかという意味で、ルーチンの真のコストだからです。 .

• これらすべてのデータ行の中で、問題になる可能性が高いのは、ルーチンが含まれているものです。コードがデバッグ情報なしでコンパイルされている場合、「不明なフレーム」はおそらくあなたのコードのようです。一般に、デバッグ情報を使用してプロファイリングし、高速化してから、デバッグ情報を削除することをお勧めします。