codebehind быстрее, чем встроенный код?
Я лично не сохранил бы различное содержание в различных ответвлениях; в случае документов и кода, я просто сделал бы myproject.git и myproject-docs.git (и подмодуль документы в код, если бы это было необходимо для процесса сборки).
, С другой стороны, ничего плохо не произойдет, если Вы сделаете это. Мерзавец не собирается говорить Вам, что сделать, таким образом, Вы свободны принять свое собственное решение о том, как Вы хотите использовать его. Таким образом для ответа на вопрос это ни уничтожающая функция, ни что-то, что будет шокировать Вас, если Вы не будете осторожны. Это как кто-то choses для использования его.
5 ответов
Встроенный код может требовать компиляции при первом запросе. После этого (или если он предварительно скомпилирован) между ними нет абсолютно никакой разницы.
Кстати, даже если он требует компиляции, разница в скорости должна быть незначительной, поскольку ASP.NET все равно придется компилировать исходный файл. Разница сводится к добавлению нескольких строк кода в большой исходный файл!
Да, иш ... Если вы компилируете во время выполнения, вы всегда будете дороже, чем то, что не обязательно, но эта компиляция будет кэширована ( если хотите) после первого запроса, так что с тех пор вы не получите никакой разницы.
Вероятно, есть кто-то, кто знает другую причину, но, на мой взгляд, единственная реальная цель для встроенных - это возможность делать горячие исправления без перестройки + повторное развертывание: то, что вы можете делать в небольших или ранних проектах разработчиков. Лично я также нахожу встроенный немного ... эстетически неприятным.
Страницы aspx должны быть проанализированы и скомпилированы в любом случае, поскольку ASP.Net превращает их в классы, которые наследуются от кода программной части (отсюда и атрибут наследования в директиве страницы), поэтому компиляция необходима в любом случае . Разница между ними для первых запусков будет незначительной, если мы не говорим о нескольких тысячах строк кода.
Но я согласен с anna: inline неприглядно.
Я не уверен, имеет ли созданная в результате сборка атрибут AllowOptimize, установленный на on или off. Я не могу найти документации, которая бы указала на это в любом случае.
Таким образом, возможно, что результирующий код не будет оптимизирован JIT таким же образом.
Я сомневаюсь, что это имеет какое-то существенное значение (как я уже сказал, этим можно управлять каким-то другим способом), но, безусловно, это могло бы повлиять на определенные операции, если бы оно, например, отключило встраивание, и у вас был большой, чрезвычайно жесткий цикл. Такая конструкция, вероятно, будет плохим выбором на странице asp.net, так что это не должно быть проблемой.
Нет. Если вы не используете веб-проект, сайт необходимо компилировать при первом обращении. Это в некоторой степени влияет как на встроенный, так и на задний код. После этого они бегут примерно с той же скоростью.