1

少し剛体シミュレーションに取り組んでいます。表示には Irrlicht エンジンを使用し、メッシュの操作には openMesh を使用します。

ここで、VerySleepy を使用してアプリのプロファイリングを行ったところ、ほとんどの時間が次の関数で費やされていることに気付きました (サブ関数で費やされた時間は除きます)。

RtlCompareMemoryUlong モジュール「ntdll」ソースファイル内の 30%「不明」

モジュール「ntdll」ソースファイル「不明」内の KiFastSystemCallRet 21%

モジュール「ntdll」ソースファイル内のRtlFillMemoryUlong 9%「不明」

そのため、時間の 50% はこれらの関数に費やされており、コードのどこかからそれらを呼び出すことはなく、それらが何をしているのか理解できません。非常に単純なメッシュしか表示していないため、グラフィックに関連しているとは思えません。

これらの関数が呼び出される理由とそれを取り除く方法を理解する方法について、誰かがヒントを教えてくれますか?

ありがとう！

4

6 に答える 6

5

ntdll は NT カーネル関数です。低レベルの操作を行うために他の関数の内部で呼び出される可能性があるため、それらに多くの時間が費やされているのはなぜですか-それらは高レベルの機能のサブビルディングブロックです。それらを無視して、パフォーマンスの調整のために他の場所 (コールスタックを上) を探します。アプリケーションから OS 呼び出しを取り除くことができない可能性があります。;)

于 2009-12-27T01:39:52.813 に答える
4

パフォーマンスの問題は、おそらく、これらの関数自体ではなく、これらの関数が頻繁に呼び出されていることです。何に使われているかは名前から推測できます。特に KiFastSystemCallRet は、アプリがカーネル モードになったことを示します。

プロファイル内の ntdll 関数を無視し、作成/制御する関数のみに注目してください。

于 2009-12-27T01:41:09.910 に答える
3

より良いプロファイラーを使用してください。OS X では、Xcode に付属のCPU Instrumentsアプリが優れた診断情報を提供し、パフォーマンスの問題を簡単に特定できます。

あなたが見たいのは、この間ずっとコールスタックです。これにより、どのライブラリと関数が常にその OS 関数を呼び出しているかがわかります。それがわかれば、そのライブラリ関数を呼び出す頻度を減らすだけです。

于 2009-12-27T01:42:44.960 に答える
1

RtlCompareMemory / RtlFillMemory は、おそらく memcmp() / memset() の基礎となる実装であるように聞こえます。

とにかく、プロファイラーの設定を変更して、呼び出し元のアプリ/ライブラリ関数の下でシステム呼び出し時間を表示し、呼び出しが最終的にどこから来ているかを確認できるようにする必要があります。

于 2009-12-27T06:02:52.560 に答える
0

フランク・クルーガーは正しい。プログラムの実行中は、コール スタックを把握する必要があります。なぜそうなるのかを簡単に説明します。 特別なツールや多数のサンプルが必要ないことに驚くかもしれません。

于 2009-12-27T03:59:42.703 に答える
0

常にシステムで立ち往生している場合は、実際の問題の一部ではなく、症状の一部としてそれを理解する必要があります.

通常、メモリの断片化とページアウトが疑われますが、無数の可能性があります。

私の経験では、具体的に何かを呼び出しているように、パフォーマンスの問題が明白なことはめったにありません。一般的に提案されているような最適化は、通常、非常に低いレベルでは役に立ちません。何かを割り当てて何度も削除するなど、正しいが通常は意図しないバグに相当するものをキャッチしますが、このようなことについては、問題がどこにあるかを正確に把握するために、起こっていることすべてを深く理解する必要があることがよくあります (ただし、私のように)システムコールで行き詰まっている場合、驚くべきことにメモリ管理に関連することがよくあります）。

于 2009-12-27T09:52:32.363 に答える