私が取り組んでいるソフトウェアはプラグイン DLL であり、通常の実行中はすべて正常に動作し、期待どおりに動作しますが、ホストがモジュールをアンロードすると、メモリの割り当て解除が遅くなります (オブジェクトのいくつかの配列が "delete[]" を介して割り当て解除されます。すべての「delete []」命令をなくすと、モジュールのアンロードがはるかに高速になります)。これはデバッグ ビルドでのみ発生し、リリース ビルドはすぐにアンロードされます。また、デストラクタの 1 つにブレークポイントを配置すると、デバッグも遅くなることにも気付きました (1 命令あたり平均 2 秒かかります)。なぜこれが起こるのかについてのアイデアはありますか?
2 に答える
あなたのケースについてはわかりません。MS IDE およびデバッグ ビルドで同様の現象が見られ、メモリ リークが報告されています。何らかの理由で多くのオブジェクトがリークした場合、それらを出力ウィンドウに報告するのにかなりの時間がかかりました。
サイキック デバッグ ハットを有効にして、VC++ を使用していると仮定します。これは重要な情報であり、提供されていないため推測する必要があります。
次に、「1 命令あたり平均 2 秒かかる」と言います。「命令」がアセンブリ言語命令を意味する場合、それはデバッガの実行速度が遅いという別の問題です。ブレークポイントの設定が多すぎる(https://randomascii.wordpress.com/2011/07/02/xperf-and-visual-studio-the-case-of-the-breakpoint-hangs/)、ソースセットにスレッドを表示する ( https://randomascii.wordpress.com/2013/03/03/visual-studio-single-step-performance-fixes/ )、またはその他の考えられる原因があります。ただし、これはデバッガの問題であり、デバッグ ビルドの問題ではありません。
デバッガーで実行すると、Windows ヒープの実行が遅くなります。追加のチェックが行われます。それが問題になる可能性がありますが、デバッグ ビルドを実行しているかどうかとは無関係であることに注意してください。
CRT ヒープは、デバッグ ビルドでの実行が遅くなり、すべての割り当てと解放でロックを取得し、割り当てをシリアル化します。また、_CRTDBG_CHECK_ALWAYS_DF が設定されている場合は、割り当てと解放のたびにヒープ全体の一貫性がチェックされるため、速度が桁違いに低下する可能性があります。
どちらが本当の問題かを知る唯一の方法は、プロファイルを作成することです。