16

本番リリースのPDBファイルをいつ含める必要がありますか？フラグを使用する必要がOptimize codeありますか？それは例外から取得する情報にどのように影響しますか？

顕著なパフォーマンス上の利点がある場合は、最適化を使用したいと思いますが、そうでない場合は、正確なデバッグ情報が必要です。本番アプリでは通常何が行われますか？

4

3 に答える 3

19

スタック トレースでソース ファイル名と行番号を確認する場合は、pdb-only オプションを使用して PDB を生成します。最適化は PDB の生成とは別のものです。つまり、パフォーマンスに影響を与えずにPDB を最適化および生成できます。

C# 言語リファレンスから

/debug:full を使用する場合は、JIT 最適化コードの速度とサイズにある程度の影響があり、/debug:full を使用するとコードの品質にわずかな影響があることに注意してください。リリース コードを生成するには、/debug:pdbonly または PDB を使用しないことをお勧めします。

于 2008-09-03T15:03:14.220 に答える
16

最初の質問に答えるには、例外レポートの行番号が必要な場合にのみ、製品リリースの PDB を含める必要があります。

2 番目の質問に答えるには、PDB で「最適化」フラグを使用すると、スタックの「崩壊」がスタック トレースに反映されます。報告された実際の行番号が間違っている可能性があるかどうかはわかりません。これにはさらに調査が必要です。

3 番目の質問に答えるには、巧妙なトリックで両方の長所を活かすことができます。デフォルトのデバッグ ビルドとデフォルトのリリース ビルドの主な違いは、デフォルトのリリース ビルドを実行すると、最適化がオンになり、デバッグ シンボルが出力されないことです。したがって、次の 4 つの手順で行います。

  1. デバッグ シンボルを発行するようにリリース構成を変更します。これはアプリのパフォーマンスにほとんど影響を与えず、アプリのリリース ビルドをデバッグする必要がある場合 (いつ?) に非常に役立ちます。

  2. 新しいリリースのビルド構成を使用して、つまりデバッグ シンボルと最適化を使用してコンパイルします。コードの最適化の 99% は、言語コンパイラではなく、JIT コンパイラによって行われることに注意してください。

  3. アプリのフォルダーに xxxx.exe.ini (または dll など) という名前のテキスト ファイルを作成します。ここで、xxxx は実行可能ファイルの名前です。このテキスト ファイルは、最初は次のようになります。

    [.NET Framework Debugging Control]
GenerateTrackingInfo=0
AllowOptimize=1

  4. これらの設定により、アプリは最高速度で実行されます。デバッグ トラッキングをオンにし、場合によっては (CIL) コード最適化をオフにしてアプリをデバッグする場合は、次の設定を使用します。

    [.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

EDIT cateye のコメントによると、これはASP.NET などのホスト環境でも機能します。

于 2008-09-18T19:55:11.630 に答える
3

それらをディストリビューションに含める必要はありませんが、それらをビルドして保持することは間違いありません。そうしないと、クラッシュ ダンプをデバッグすることは事実上不可能です。

最適化もオンにします。デバッグはより困難になりますが、パフォーマンスの向上は通常、アプリケーションの性質によっては非常に重要です。一部のアルゴリズムでは、リリース ビルドとデバッグ ビルドで 10 倍を超えるパフォーマンスが簡単に確認できます。

于 2008-09-03T15:03:59.740 に答える