ASP.NET compilationMode Авто против Никогда - PullRequest
Новая
       15

ASP.NET compilationMode Авто против Никогда

3 голосов
/ 13 сентября 2009

Давайте предположим, что на моей странице ASPX нет встроенных блоков кода C #.

Итак, я могу смело установить 

<pages compilationMode="Never" />

... в моем файле web.config и не беспокойтесь об ошибках компиляции.

По производительности, будет ли штраф за использование следующих настроек? 

<pages compilationMode="Auto" />

т.е.. "автоматическое" обнаружение занимает какое-то значительное время?

Ответы [ 3 ]

3 голосов
/ 13 сентября 2009

Влияние Авто выглядит очень незначительным. (Хотя, очевидно, больше, чем Никогда ).

Если мы рассмотрим код в 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>.*?)%>";
    ...
}

Если он не встречает ничего, он просто движется дальше. Поиск является довольно недорогой операцией - самый большой удар - это когда блоки кода на самом деле найдены и скомпилированы.

2 голосов
/ 17 октября 2009

Я не уверен, что согласен с предположением, что Авто должен быть более производительным, чем Всегда . По этому вопросу есть аналогичный вопрос, и я думаю, что в конечном итоге ' Авто ' (и некомпилированные страницы в целом) были введены в качестве средства, обеспечивающего лучшую масштабируемость, не обязательно лучшую производительность (за пределами начальной компиляции / разбора).

Если Авто был бы более производительным в каждом сценарии, почему бы не использовать его по умолчанию?

Приложения, которые имеют небольшое фиксированное количество сборок, выиграют от стандартной настройки Always и предварительной компиляции всего сайта; для сценариев CMS-esque, таких как SharePoint, где страницы изменяются во время выполнения, Авто является единственным вариантом из-за необходимости сдвига.

То, что я затрудняюсь объяснить в нашем сценарии (несколько сотен сборок, не изменяющихся во время выполнения), заключается в том, почему % времени в JIT колеблется и иногда превышает 60%, намного позже приложение было разогрето и даже с предварительной компиляцией всего сайта? Если это обычное явление при развертывании 200-500 сборок, то я вижу преимущество Авто и в этих сценариях.

0 голосов
/ 13 сентября 2009

Авто должен быть более производительным, чем Всегда , и является безопасным средством отработки отказа при добавлении встроенного кода C #.

Дополнительное время будет потрачено на определение необходимости компиляции страницы, что добавляет немного накладных расходов по сравнению с опцией Никогда .

...