views:

316

answers:

3

Let's assume my ASPX page has no inline C# code blocks.

So, I can safely set

<pages compilationMode="Never" />

...in my web.config file and not worry about compilation errors.

Performance-wise, would there be any penalty to using the following setting?

<pages compilationMode="Auto" />

i.e. does the "auto" detection take any significant amount of time?

A: 

Auto should be more performant than Always, and is a safe failsafe for when you do add inline C# code.

Extra time will be spent determining if a page needs to be compiled, which adds a little overhead in comparison to the Never option.

David Andres
+2  A: 

The impact of Auto appears to be very little. (Although obviously more than Never).

If we examine the code in System.Web.UI.TemplateParser, we see in ImportSourceFile that process is aborted early if mode is set to Never:

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

Which is of course helpful, and definitely the lowest-impact. However, continuing through the routines in TemplateParser, we can see in ParseStringInternal the parser literally scans the loaded template searching for variations of <%:

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);
    }
}

Note the BaseParser.aspCodeRegex, which is an instance of this pattern:

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

If it encounters none, it simply moves on. The searching is a fairly inexpensive operation - the biggest hit is when code blocks are actually found, compiling them.

Rex M
How were you able to view the code of System.Web.UI.TemplateParser?Great answer BTW.
frankadelic
@frankadelic Cheers! I use **Reflector** (http://red-gate.com/products/reflector) - the best documentation is the code itself :)
Rex M
+1  A: 

I'm not sure I agree with the suggestion that Auto should be more performant than Always. There's a similar question on this and I think that ultimately 'Auto' (and non-compiled pages, in general) were introduced as a means to offer better scalability, not necessarily better performance (beyond the initial compilation/parse overhead).

If Auto was more performant in every scenario, why wouldn't it be the default?

Applications that have a small, fixed number of assemblies would benefit from the standard Always setting and site-wide pre-compilation; for CMS-esque scenarios, like SharePoint, where pages are changed at run-time, Auto is the only option, out of shear necessity.

What I'm at a loss to explain in our scenario (few hundred assemblies, not changing at run-time) is why % Time in JIT is fluctuating and occasionally higher than 60%, long after the app has been warmed up and even with site-wide pre-compilation? If this common with 200-500 assembly deployments, then I can see the benefit of Auto in those scenarios as well.

Nariman
Interesting stuff... I am using "Auto" to get around app domain restarts when my ASPX pages change. However, I still have the issue when .resx files change http://stackoverflow.com/questions/1535027
frankadelic
Funny you should mention that - looks like we're wrestling with the same issues! There's a straightforward workaround for resx files (see the answer posted).
Nariman