5

MySql Connector .NETを使用してアカウントをロードし、それをクライアントに転送しています。アカウントの子要素をロードすることを考えると、この操作はかなり集中的です。

デバッグモードでは、アカウントの読み込みに最大で1秒かかります。平均は500msになります。リリースモードでは、アカウントの読み込みに1〜4秒かかります。平均は1500msになります。

#if DEBUG私のコードにはディレクティブなどがないので、どこから違いがあるのか​​気になります。

変更できるプロジェクトビルドオプションはありますか？または、ビルドモードに応じて動作が異なるMySql Connector .NETと関係がありますか？

編集：ダニの監視。

Debug (Average: 213000 ticks)
730000
320000
60000
50000
190000
130000
210000
180000
160000
110000
390000
270000
150000
190000
230000
210000
150000
200000
190000
140000

Release (Average: 4404500 ticks)
12940000
170000
180000
80000
80000
130000
120000
5060000
5090000
130000
50000
10430000
25160000
150000
160000
130000
17620000
10160000
100000
150000

比較：

リリースには、デバッグにかかる​​時間の20倍かかります（平均比較）。

4,404,500 / 213,000 = 20

現在、最初の操作は確かに長くなっていますが、一般的には、他のすべての時間もリリースされます。何か案が？

編集2：合計時間を計算するさらに広範なテストを追加しました。アカウントの読み込みが50回の場合、デバッグには平均4秒、リリースには平均40秒かかります。私はこれについてかなり必死になり始めています-それは私のアプリケーションにとって深刻なパフォーマンスの問題です。誰かがこれを修正する方法について推測していますか？

4

3 に答える 3

8

タイミングの違いは、操作に必要なアセンブリがロードされるタイミングの変更が原因である可能性があります。

リリースモードでは、ランタイムは、操作で後で必要になるだけのアセンブリをすぐにロードする必要がない場合があります（リリースビルドに対して実行されるさまざまな最適化のため）。その結果、デバッグモードでは、操作のタイミングを開始する前にアセンブリが読み込まれる場合があり、リリースモードでは、操作のタイミングを開始した後にアセンブリが読み込まれる場合があります。アセンブリの大きさによっては、アセンブリをロードする時間が長くなる可能性があります。もちろん、どちらの場合もアセンブリをロードする必要があり、ロードする必要があるのは1回だけなので、リリースモードでの後続の実行はより高速になる可能性があります。

ループ内で操作を数回実行し、最初の実行を無視して、起動時のオーバーヘッドが平均的に少ないことを確認してください。

更新： リリースモードのタイミングがデバッグモードのタイミングと比べて大きく異なることは興味深いです（リリースモードの標準偏差は100倍高くなっています）。下端では、リリースモードのタイミングはデバッグモードのタイミングに匹敵します。あなたはあなたの質問で、ロードしなければならないすべての子要素のためにアカウントのロードが集中的であると述べています。もう1つの違いは、ランタイムがガベージコレクションの実行を決定するポイントである可能性があります。テストするには、System.GC.Collect()各操作の後に（タイマーの外で）実行してみて、それによって状況が変わるかどうかを確認できます。

更新： ロックに関する動作に変更があると思われる場合は、Windowsパフォーマンスモニターを使用して、デバッグとデバッグの両方でテストを実行している間、アプリケーションのプロセスのさまざまな.NETCLRLocksAndThreadsカウンターを監視することを検討してください。リリースモード。おそらく、どこかでロックを適切に解放しておらず、タイムアウトが経過するまで実行が遅れていますか？もしそうなら、パフォーマンスカウンターによって報告される競合率の増加が見られると思います。これがリリースビルドでのみ問題になる理由はわかりません（デバッグビルドの実行時に実際にデバッガーを使用している場合を除く）。

于 2010-04-06T03:32:42.017 に答える
2

アプリケーションのプロパティ設定の[ビルド]タブと[デバッグ]タブはすべて、ビルド構成に応じて変更される可能性があります。これらの一部はコンパイル段階のみを参照し、実行時のパフォーマンスには影響しません（安全でないコードの許可、エラーと警告、警告をエラーとして扱う、XMLドキュメントファイル）。他の人は違いを生む可能性があります。

構成間で異なる各設定に注意し、構成が一致するように各設定を変更して、各変更間でテストします。そうすれば、問題の原因を見つけることができるはずです。

特に、DEBUG定数の定義、TRACE定数の定義、条件付きコンパイルシンボル、プラットフォームターゲット、コードの最適化、（詳細画面で）算術オーバーフロー/アンダーフローの確認、シリアル化アセンブリの生成、アンマネージコードのデバッグの有効化、およびVisualStudioホスティングの有効化をテストします。処理する。

于 2010-04-08T19:24:58.757 に答える
1

私はそれを理解しました、私は私の依存関係ビルドの1つで安全でないコードを許可しました。なぜそれがそのように振る舞うのかまだ疑問に思っていますが、これをもう少し掘り下げる必要があります。

ご協力ありがとうございます！

于 2010-04-13T17:10:23.457 に答える