假設我的ASPX頁面沒有內嵌C#代碼塊。ASP.NET compilationMode自動VS決不
所以,我可以放心地設置
<pages compilationMode="Never" />
...在我的web.config文件,而不必擔心編譯錯誤。
性能方面,會有任何懲罰使用下面的設置?
<pages compilationMode="Auto" />
即「自動」檢測是否需要大量時間?
假設我的ASPX頁面沒有內嵌C#代碼塊。ASP.NET compilationMode自動VS決不
所以,我可以放心地設置
<pages compilationMode="Never" />
...在我的web.config文件,而不必擔心編譯錯誤。
性能方面,會有任何懲罰使用下面的設置?
<pages compilationMode="Auto" />
即「自動」檢測是否需要大量時間?
自動的影響似乎很小。 (雖然明顯多於從不)。
如果我們檢查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<%([email protected])(?<code>.*?)%>";
...
}
如果遇到沒有,它只是繼續前進。搜索是一個相當便宜的操作 - 最大的影響是當代碼塊被發現時,編譯它們。
自動應該比始終更好的性能,並且是當你添加內嵌C#代碼的安全故障安全。
花費額外的時間來確定是否需要編譯頁面,與Never選項相比,這會增加一些開銷。
我不確定我是否同意汽車應該比總是的建議。有一個關於這個similar問題,我認爲,最終「自動」(和非編頁,一般)被引入,以提供更好的擴展性,不一定更好的性能(超出了最初的編譯/解析開銷)的手段。
如果自動在每種情況下都更高性能,爲什麼它不是默認設置?
具有小型固定數量組件的應用程序將受益於標準總是設置和站點範圍內的預編譯;對於像CMS這樣的CMS風格的場景,在運行時更改頁面的位置,自動是唯一的選擇,超出剪切的必要性。
在我們的情況下(幾百個程序集,不會在運行時更改),我無所適從,這就是爲什麼%JIT中的時間波動且偶爾高於60%被預熱,甚至在整個網站進行預編譯?如果這與200-500裝配部署相同,那麼在這些情況下我也可以看到Auto的好處。
有趣的東西...我使用「自動」來解決應用程序域重新啓動當我的ASPX頁面改變時。但是,當.resx文件更改時,我仍然遇到這個問題http://stackoverflow.com/questions/1535027 – frankadelic 2009-12-04 23:32:02
有趣的是,你應該提及 - 看起來我們正在摔跤相同的問題!對於resx文件有一個簡單的解決方法(請參閱發佈的答案)。 – Nariman 2009-12-05 21:28:37
您如何查看System.Web.UI.TemplateParser的代碼? 好的答案順便說一句。 – frankadelic 2009-09-13 16:01:12
@frankadelic乾杯!我使用**反射器**(http://red-gate.com/products/reflector) - 最好的文檔是代碼本身:) – 2009-09-13 16:06:20