0

道路網でいくつかの検証チェックを実行する ESRI ArcEditor 用のプラグインを作成しました。ルールがすべて満たされているかどうかを確認するために、基本的に、選択したフィーチャに対していくつかのバッファリングやエンベロープなどを使用して、さまざまな交差を多数実行します。

C#で書かれています。

今気づいたのは、選択した機能に対して特定のアルゴリズムを実行するには、実際には長い時間がかかるということです。私はANTSプロファイラーをロードし、他にできることがほとんどなくなるまでボトルネックを最適化しました.

私が気付いた奇妙なことは、ANTS がタイムラインで実質的に CPU 使用率を報告していないことです。つまり、フラットラインです。次に、検証操作の実行中にタスク マネージャーを使用して、プロセッサが約 10% から 15% 未満にとどまっていることを確認しました。これは私には意味がありません。使用可能なプロセッサー・サイクルを使用していないのはなぜですか?

ArcSDE からすべてをロードするため、I/O は発生しません。また、検証プロセス中にかなりのネットワーク トラフィックがないことも確認しました。これは、おそらく ArcEditor とサーバー間の通信を待っているためだと考えています。次に、サーバー上のプロセッサをチェックして、処理が委任されていないことを確認しましたが、検証プロセス中、CPU 使用率は 1% で安定していました。

次に、ArcEditor がプラグインを実行できる優先度を抑制している、またはそのようなおかしなことをしているのではないかと考えました。そこで、検証ルーチンの代わりに、約 10 秒間 CPU を最大化する数学演算をプラグインしたところ、まさにそれが実行されました。CPU 使用率は 50% 強で安定していました。これは、数学演算が Core 2 Duo のコアの 1 つを使い果たしてしまうことを考えると理にかなっています。だから運がない。また、1GB 以上の RAM が利用可能です。

最後に、perfmon の問題を見つけようとしましたが、うまくいきませんでした。あまり経験がありませんが、何か悪いことは見つかりません。

ArcObjects COM インターフェイスが原因ですか? perfmon で .NET Interop カウンターもチェックしましたが。

私は途方に暮れています。

そのため、どんな助けやヒントも大歓迎です。

4

1 に答える 1

1

スレッドの問題である可能性があります。COMは、COMインターフェイス上のメソッド呼び出しを適切なスレッドに自動的にマーシャリングします。これは通常、プログラムのUIスレッドです。スレッドコンテキストスイッチが必要であり、UIスレッドが呼び出しをディスパッチする状態である必要があるため、これは非常に低速です。消費されるCPUサイクルはほとんどなく、呼び出しが完了するまですべてがブロックされます。

作成されたのと同じスレッドでCOMオブジェクトを使用します。このオブジェクトにSTA要件がある場合、これはUIスレッドである必要があります。彼らは通常そうします。

于 2010-08-26T16:52:26.450 に答える