タブにページ コントロールやさまざまなグリッドなどを含む D2006 アプリがあります。メイン フォームのサイズを変更すると (何かに合わせてフォーム上のほぼすべてが波及してサイズ変更されます)、数秒などの長い遅延が発生します。アプリがフリーズし、アイドル ハンドラーが呼び出されず、実行中のスレッドも停止しているように見えます。
問題のあるコード内で実行を中断しようとして、これが発生している間、IDE で実行を一時停止しようとしましたが、IDE はメッセージを受け取りません。
明らかに、誰かが間違ったコードを指摘してくれるとは思っていませんが、助けになる可能性のあるアプローチをデバッグした後です。アプリ全体に大規模な実行タイミング コードがあり、長い遅延はどのデータにも表示されません。たとえば、メイン フォームの OnResize ハンドラの実行時間は最小限です。
実際に時間を費やしているものを知りたい場合は、プロファイラーを試してください。 サンプリングプロファイラーOutputDebugStringは、特に問題の原因となっているコードのセクションの最初と最後を見つけて、その周りにステートメントを挿入してプロファイリングを絞り込むことができる場合は、質問に非常に簡単に答えることができます。
わかった。問題が解決しました。コマンドラインスイッチを有効にしてデバッグ情報をログに記録した場合にのみ問題が発生することに気付きました。デバッグ情報には、タブの 1 つでデバッグ ログ (TMemo) に書き込まれたいくつかの HTTP 応答が含まれていました。HTTP 応答に CR/LF のない大きなブロックが含まれている場合、TMemo はそれをラップしました。メイン フォームのサイズを変更するたびに、TMemo のサイズが変更され、コントロールは新しいワード ラッピングでテキストを再度レンダリングする必要がありました。
デモンストレーションするには：
他の誰かがそれを解決するのに十分な情報を実際に提供していなかったので、私は自分自身に答えを与えません.
ところで@Mason - SamplingProfilerはこれを拾ったでしょうか - 実行が私のコードではなくVCL内にあるとすれば？
AQTime のパフォーマンス プロファイラーでアプリケーションを実行します (XE に含まれていますが、Web サイトから期間限定バージョンを入手できます)。
しばらくの間、熱狂的なサイズ変更を行ってから、アプリケーションを停止します。
その後、どの関数が何度も呼び出され、どこで最も時間が費やされたかが正確にわかります。
結果をもたらす可能性のある力ずくのアプローチ.... すべてのサイズ変更イベントからデバッグ メッセージを OutputDebugString() に入れ、コントロールの名前を表示する文字列として送信します。これにより、どれが「多く」と呼ばれているかがわかります。
コントロールが互いに衝突し、カスケード サイズ変更イベントが発生する場合があります。コンパクトカーの後部座席にいる 3 人の兄弟のように、位置を争うようになると、「落ち着く」までに時間がかかる場合があります。
この車の向きを変えさせないで....
デバッグ ログ (IDE または外部 ODS ビューアで表示可能) は、1 つの「ユーザー開始のサイズ変更イベント」に対して複数回表示される場合、最も問題を引き起こしているログを示す場合があります。