Должен ли я использовать haml или erb или erubis для сайта с потенциально высоким трафиком?

Question

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

Тем не менее, начало работы над проектом, который, по нашему мнению, будет генерировать довольно мало трафика (а кто нет?). Я обеспокоен тем, что есть вещи, которые я просто не знаю о хамле. Есть ли что-нибудь, что эрб может сделать, чего не может хамл? Оказывает ли хамл отрицательный эффект по мере роста проекта? Есть ли другие вещи, которые следует учитывать?

И наконец ... как Хамл сравнивается по скорости с эрубисом? Я вижу, что сейчас якобы бьет эрб и эруби ...

Спасибо!

Answer 1

Хамл Рокс. Я не видел каких-либо недавних показателей производительности, но это довольно близко к эрб в наши дни. Я думаю, что это может быть быстрее, чем erb, если вы включите уродливый режим (который предотвращает красивые отступы). Мы выполняем 2,8 миллиона просмотров страниц в день с Haml.

В исходном дереве Haml проверен бенчмаркер: http://github.com/nex3/haml/tree/master/test

Обновление за ноябрь 2009

Натан (главный разработчик Haml) опубликовал несколько тестов Haml 2.2 в своем блоге. Вы можете увидеть точные цифры там, но вкратце:

• Нормальный режим (симпатичная печать) = в 2,8 раза медленнее, чем ERB
• Гадкий режим (без красивых вкладок) = равно ERB

Вы можете включить уродливый режим, поместив Haml::Template::options[:ugly] = true в файл инициализатора или окружения. Обратите внимание, что уродливый режим на самом деле не так уж уродлив - итоговый HTML на самом деле намного красивее, чем ERB, - он просто не имеет хороших отступов.

Answer 2

Если вы используете Rails, разница в производительности между Haml и erubis незначительна: шаблоны в любом случае компилируются и кэшируются после первого попадания. Объедините это с кэшированием фрагментов и страниц, и вы можете быть уверены, что представления не являются узким местом производительности вашего приложения.

Вопрос, который вы должны себе задать: вам нравится писать «Хамл»? Это делает вас более продуктивным? Тогда вы можете решить проще.

Answer 3

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

Если вы беспокоитесь о трафике, вам следует правильно использовать кеширование. И тогда вам нужно применить принципы общей производительности веб-приложений - в результате вы получите очень быстрые ответы на загрузку страниц. Вот что действительно нужно веб-сайту с большим трафиком.

Пару презентаций, показывающих, как повысить производительность сайта, можно найти здесь:

• Майкл Козьярски говорит о производительности Rails 2008 года в Париже на Rails

• Джереми Кемпер рассказывает о производительности на Rails на RailsConf EU'08

И лучшее место, которое я знаю, чтобы научиться правильно использовать кэширование рельсов:

• Скринкаст PeepCode для кэширования Rails

Answer 4

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

Однако, в случае шаблонов ERb, вы получите лучшую производительность по существу бесплатно, если будете использовать erubis.

Answer 5

Если вам нравится, как работает haml с точки зрения кодирования, не стоит слишком беспокоиться о производительности движка шаблонов. (Хотя, как вы указали, теперь это быстро.) Он может определенно генерировать любые выходные данные, которые могут другие двигатели.

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

Answer 6

Я бы лично порекомендовал нам erubis в скомпилированных шаблонах.

Особенно, если нет необходимости в динамических шаблонах. Тогда ваше самое большое замедление будет ограничено скоростью, с которой рубин может анализировать рубин.

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

Скомпилируйте один раз, используйте много.

О, и если вы действительно беспокоитесь о скорости, возможно, Тенджин тоже стоит посмотреть (те же создатели, что и Эрубис)

http://www.kuwata -lab.com / Тенджин / rbtenjin-examples.html

Answer 7

Что ж, производительность Haml продолжает улучшаться с каждым выпуском. Это в приемлемом месте в настоящее время? Это решать вам (я склонен сказать «Да», но это ваш выбор, основанный на ваших потребностях). Если вам нравятся шаблоны и удобочитаемость, которую они предоставляют, то снижение производительности (хотя и незначительное) действительно должно стать окончательным фактором вашего решения.

Одним из других инструментов, которые вы должны рассмотреть в сочетании с Haml, является make_resourceful, еще одна жемчужина сопровождающего Haml (Натана Вайзенбаума), которая упрощает многие вещи RESTful в приложении Rails.

Если у вас есть еще какие-то более конкретные вопросы о Хамле (и м_р), я уверен, что Натан был бы более чем рад ответить на них. С ним можно связаться через Jabber / XMPP и электронную почту. Его контактную информацию можно найти здесь .