Вопросы о производительности asp.net mvc (частичные представления и помощники html)

Question

Мне просто интересно, сколько производительности вы проиграете, используя множество частичных представлений и html-помощников в приложении asp.net mvc.

Как я знаю, помощники html должны быть легкими, но я не вижу их рендеринга так быстро, как если бы вы просто создали прямой html.

Не поймите меня неправильно Я люблю их, но просто интересуюсь, насколько они повлияют на ваш сайт. Я предполагаю, что не так много, но некоторые из этих html-помощников могут усложниться и сделать совсем немного.

Также мне нравится использовать частичные представления, так как многие мои части моего сайта нуждаются в основном в одном и том же коде, поэтому можно попытаться устранить дублированный код, поэтому мне нравится помещать его в частичные виды.

Какое влияние на производительность оказывают частичные виды?

Answer 1

У меня нет доказательств, подтверждающих это, но я бы почти не принял его. Специально для HTML Helpers - это просто дополнительный вызов метода. Вы можете скопировать и вставить код из помощника в представление, и вы бы выполнили только один метод в стеке.

Answer 2

Ваше серверное оборудование и сетевое инфраструктура будут более ограничивающим фактором, чем html-помощники и частичные виды. Не думай об этом.

Answer 3

Это преждевременная оптимизация. Сначала напишите его, затем профилируйте, и если вы обнаружите, что производительность не соответствует вашим требованиям/SLA, используйте инструменты профилирования, чтобы найти плохо исполняемый код. Вероятно, это не будут методы html helper, это будут такие вещи, как вызовы базы данных и другие вызовы перекрестных процессов.

Answer 4

Я вообще согласен с тем, что накладных расходов почти нет, и что это будет преждевременная оптимизация, чтобы избежать этого. Тем не менее, есть два важных исключения вы должны знать:

• Используя множество частичных взглядов будет очень медленным , когда компилятор ASP.NET компилирует в режиме отладки. В режиме отладки MVC не кэширует расположение файлов, поэтому он должен проверять каждый раз, когда он отображает представление. Не обманывайте себя! Эта проблема исчезает в режиме деблокирования.

• В сборке MVC Futures для MVC 1.0, есть некоторые «сильно типизированных» HTML хелперы, которые являются (1) о 10x медленнее, чем помощников в сборке System.Web.Mvc и (2), вероятно, несовместимые (с точки зрения синтаксиса) с (предположительно улучшенными от POV производительности) «сильно типизированные» помощники, входящие в MVC 2. Я бы предложил остаться в стороне от них.

Но в целом я согласен: Написать правильный код, а затем профиль.