4

ASPX ページにインライン C# コード ブロックがないと仮定しましょう。

ということで安心してセットできました

<pages compilationMode="Never" />

...私のweb.configファイルで、コンパイルエラーについて心配する必要はありません。

パフォーマンスに関して、次の設定を使用すると何かペナルティはありますか?

<pages compilationMode="Auto" />

つまり、「自動」検出にはかなりの時間がかかりますか?

4

3 に答える 3

4

Autoの影響は非常に小さいようです。（明らかにNever以上ですが）。

System.Web.UI.TemplateParserのコードを調べると、ImportSourceFileモードが に設定されている場合、プロセスが早期に中止されることがわかりNeverます。

if (this.CompilationMode == CompilationMode.Never)
{
    return null;
}

もちろんこれは役に立ちますが、間違いなく最も影響が少ないものです。ただし、 のルーチンを続けると、パーサーがロードされたテンプレートを文字どおりスキャンして、次のバリエーションを検索しているTemplateParserことがわかります。ParseStringInternal<%

if (!this.flags[2] && (match = BaseParser.aspCodeRegex.Match(text, startat)).Success)
{
    string str3 = match.Groups["code"].Value.Trim();
    if (str3.StartsWith("$", StringComparison.Ordinal))
    {
        this.ProcessError(SR.GetString("ExpressionBuilder_LiteralExpressionsNotAllowed", new object[] { match.ToString(), str3 }));
    }
    else
    {
        this.ProcessCodeBlock(match, CodeBlockType.Code, text);
    }
}

BaseParser.aspCodeRegexこのパターンのインスタンスである に注意してください。

public AspCodeRegex()
{
    base.pattern = @"\G<%(?!@)(?<code>.*?)%>";
    ...
}

何も遭遇しない場合は、単に先に進みます。検索はかなり安価な操作です。最大のヒットは、コード ブロックが実際に見つかったとき、それらをコンパイルするときです。

于 2009-09-13T04:10:22.227 に答える
3

AutoがAlwaysよりもパフォーマンスが高いという提案に同意するかどうかはわかりません。これには同様の質問があり、最終的に ' Auto ' (および一般にコンパイルされていないページ) は、必ずしもパフォーマンスが向上するわけではなく、スケーラビリティを向上させる手段として導入されたと思います (最初のコンパイル/解析のオーバーヘッドを超えて)。

すべてのシナリオでAutoの方がパフォーマンスが高いのであれば、なぜ Auto をデフォルトにしないのでしょうか?

少数の固定数のアセンブリを持つアプリケーションは、標準のAlways設定とサイト全体のプリコンパイルの恩恵を受けるでしょう。実行時にページが変更される SharePoint などの CMS 風のシナリオでは、せん断の必要性から、自動が唯一のオプションです。

私たちのシナリオ (実行時に変更されない数百のアセンブリ) で説明するのが途方に暮れているのは、JIT の % Timeが変動し、アプリがウォームアップされてからずっと後に 60% を超える場合がある理由です。サイト全体の事前コンパイル？これが 200 ～ 500 のアセンブリ展開で一般的である場合、これらのシナリオでもAutoの利点を確認できます。

于 2009-10-17T15:31:10.663 に答える
0

AutoはAlwaysよりもパフォーマンスが高く、インライン C# コードを追加する場合の安全なフェールセーフです。

ページをコンパイルする必要があるかどうかを判断するのに余分な時間が費やされます。これにより、 Neverオプションと比較してオーバーヘッドが少し増えます。

于 2009-09-13T04:08:44.443 に答える