ASP.NET 编译模式“自动”与“从不”

Question

假设我的 ASPX 页面没有内联 C# 代码块。

因此，我可以安全地

<pages compilationMode="Never" />

在 web.config 文件中设置 ...，而不必担心编译错误。

从性能角度来看，使用以下设置会有任何损失吗？

<pages compilationMode="Auto" />

即“自动”检测是否需要花费大量时间？

Answer 1

自动的影响似乎很小。 （尽管显然比从不多）。

如果我们检查 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>.*?)%>";
    ...
}

如果没有遇到，它就会继续前进。搜索是一个相当便宜的操作 - 最大的打击是当实际找到代码块并编译它们时。

Answer 2

我不确定我是否同意自动应该比始终性能更高的建议。关于此有一个类似问题，我认为最终“自动””（以及一般的非编译页面）是为了提供更好的可扩展性，而不一定是更好的性能（超出初始编译/解析开销）。

如果自动在每种情况下都具有更高的性能，为什么不将其作为默认设置呢？

具有少量、固定数量的程序集的应用程序将受益于标准的始终设置和站点范围的预编译；对于类似 CMS 的场景，例如 SharePoint，页面在运行时更改，出于剪切的需要，自动 是唯一的选项。

在我们的场景中（几百个程序集，在运行时不改变），我无法解释为什么 % Time in JIT 在应用程序运行后很长时间内波动，有时会高于 60%已经预热，甚至进行了全站预编译？如果这在 200-500 个程序集部署中很常见，那么我也可以在这些场景中看到自动的优势。

Answer 3

自动 应该比始终 具有更高的性能，并且在您添加内联 C# 代码时是一种安全的故障保护。

将花费额外的时间来确定是否需要编译页面，这与从不选项相比增加了一些开销。