4

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

所以，我可以安全地设置

<pages compilationMode="Never" />

...在我的 web.config 文件中，不用担心编译错误。

性能方面，使用以下设置是否会受到任何惩罚？

<pages compilationMode="Auto" />

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

4

3 回答 3

4

Auto的影响似乎很小。（虽然显然不止Never）。

如果我们检查System.Web.UI.TemplateParser中的代码，我们会看到ImportSourceFile如果 mode 设置为，该进程会提前中止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在每种情况下都具有更高的性能，那为什么不是默认设置呢？

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

在我们的场景中我无法解释（几百个程序集，在运行时没有改变）是为什么JIT中的时间百分比会波动，有时会高于 60%，在应用程序已经预热很久之后甚至全站预编译？如果这在 200-500 个装配部署中很常见，那么我也可以看到Auto在这些场景中的好处。

于 2009-10-17T15:31:10.663 回答
0

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

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

于 2009-09-13T04:08:44.443 回答