2012-01-01 7 views
2

パフォーマンスをテストしています。プログラムは、TCP接続を介して他の側から巨大なバイトを受け取り、ターゲット構造を解析します。デバッグモードとリリースモード間のパフォーマンステスト

デバッグ(F5)で試してみると、非常に遅れています。しかし、リリース(Ctrl + F5)で試してみると、非常にスムーズに動作します。 WireShark、TCPウィンドウの更新ステートメントを使用して状況を確認し、受信側の状況を知らせます。

エンドユーザープログラムを作成したいのですか?プログラムはデバッグモードとリリースモードで動作するはずですか?

データサイズが非常に大きく、送信間隔が非常に短い。この場合、デバッグとリリースのパフォーマンスの違いは非常にクリアなものになりますか?私はそのような違いは今までには見られなかった。

+2

パフォーマンステスト「デバッグ」ビルドは無駄です。あなたのアプリが「リリース」モードで期待どおりに動いていれば、すべてうまくいきます。それ以上の睡眠を失う必要はありません。 **決して** "Debug"バージョンをクライアントにデプロイしないでください。 –

答えて

0

アプリケーションを公開するときは、「リリース」モードでのみコンパイルする必要があります。デバッグモードは、開発中に実際に「デバッグ」するために使用されます。

0

リリースモードのみを考慮してプログラミングする必要があります。それは実際にエンドユーザーに届くべきあなたのアプリの唯一のバージョンです。デバッグモードは "ハウスキーピング"とか、よく...デバッグのためだけです。ユーザーの心配ではありません。

+1

リリースモードでは* profile *のみにする必要があります。デバッグビルドは、コードが正しいことを確認するためのアサートやその他のエラーチェックを含む必要があるため、できるだけ使用する必要があります。 –

1

この質問には2つの異なる問題があります。 1つはデバッグとリリースのビルドです。デバッグビルドは、デバッグを容易にすることを目的とした、さまざまな理由で低速です。

2番目の問題は、デバッガ(F5)でアプリケーションを起動し、デバッガ(Ctrl + F5)で起動しないとパフォーマンスが低下することです。 Windowsヒープは、デバッガの下で起動されたときに追加チェックを行い、OutputDebugStringの処理とモジュールのロードに時間がかかることがあります。

これらの2つの問題は完全に直交しています。デバッガでリリースビルドを起動することもできますし、デバッガをデバッガで起動することもできます。

問題がデバッグビルドの方が遅い場合は、そうです。いくつかのソースファイルで最適化を有効にするか、デバッグイテレータをオフにすることで、これをややこしく制御できますが、デバッグビルドはやや遅くなるはずです。

デバッガの下でビルドされたビルドが遅いという問題がある場合は、パフォーマンスを気にするときにそれをしないでください。後でデバッガを接続することができます。これにより、減速の一部を回避したり、デバッガを一切アタッチしたりしません。

関連する問題