Вышел (http://community.livejournal.com/ru_highload/100249.html) релиз шаблонизатора CTPP 2.6.1 (http://ctpp.havoc.ru/) - аналога библиотек Template Toolkit, HTML::Template, HTML::Template::Pro, Smarty, отличающегося высокой скоростью работы (в 2 - 3 раза быстрее HTML::Templte::JIT, в 25 - 30 раз быстрее Template Toolkit), расширяемостью функционала и удобством работы. CTPP написан на языке С++ и распространяется в рамках BSD-подобной лицензии. Программные интерфейсы разработаны для языков Perl, PHP и Python.
В ветке 2.6 добавлены следующие улучшения:
- Возможность сравнения строк и чисел в строковом и числовом контексте;
- Поддержка несколько новых синтаксисов (TT, smarty, asp-like);
- Новые функции и переменные, например, HASH_ELEMENT, _RCOUNTER__ и __OUTER__;
- Более удобный API;
- Улучшенный вывод ошибок времени компиляции и исполнения;
- Улучшена работа виртуальной машины (меньше размер кода шаблонов, выше скорость работы);
- Расширена документация, добавле...URL: http://community.livejournal.com/ru_highload/100249.html
Новость: http://www.opennet.me/opennews/art.shtml?num=27035
/r/ бенчмарки в сравнении с jinja2
CTPP на порядок-два быстрее. Jinja2 на Python, а CTPP на C++ и шаблоны не интерпретирует, а как байткод выполняет. В частности CTPP используется в mail.ru на фронтэнде, да-да CTPP настолько быстр, что им на фронтэнде шаблонизируют контент, бэкенды mail.ru отдают данные в JSON.
"Порядок-два" - это 10-100 раз, вы уверены? оО
>"Порядок-два" - это 10-100 раз, вы уверены? оОВполне, если CTPP в несколько раз шаблонизаторы на Си обгоняет, то обогнать шаблонизатор на Python в 10-100 раз не проблема.
> не интерпретирует, а как байткод выполняетМожно пояснить смысл этой фразы?
>> не интерпретирует, а как байткод выполняет
>
>Можно пояснить смысл этой фразы?Шаблоны в CTPP перед выполнением компилируются в байткод. Компиляция происходит один раз, при загрузке шаблона. Соответственно, сильно экономится время на парзинге шаблонов (парзится один раз, исполняется - много).
Шаблоны это не то место которое требуется в оптимизации. По крайней мере в моём опыте проседание производительности даже на самых медленных шаблонизаторах было не значительным и не стоило внимания. Ну может я что-то не так делал :-).
К тому же отдельные элементы сложно-составной генерируемой страницы всегда можно закешировать, да хоть этим вашим memcache, и повысить таким образом производительность в тыщапятьсот раз, относительно постоянного использования шаблонизатора. Хотя опять же, выигрыш получается больше за счёт того же сокращения числа запросов к базе (грубо говоря)...bw
>[оверквотинг удален]
>в моём опыте проседание производительности даже на самых медленных шаблонизаторах было
>не значительным и не стоило внимания. Ну может я что-то не
>так делал :-).
>К тому же отдельные элементы сложно-составной генерируемой страницы всегда можно закешировать, да
>хоть этим вашим memcache, и повысить таким образом производительность в тыщапятьсот
>раз, относительно постоянного использования шаблонизатора. Хотя опять же, выигрыш получается больше
>за счёт того же сокращения числа запросов к базе (грубо говоря).
>
>
>..bwШаблоны - действительно не то место, где требуется оптимизация, ЕСЛИ остальная часть логики сама по себе работает медленно. Грубо говоря, нет смысла тюнить шаблонизатор, если SQL-запросы выполняются по секунде.
В случае, когда бизнес-логика работает быстро, скорость рендеринга шаблона становится одним из определяющих моментов.
Практика показывает , что лучше кэшировать не отдельные элементы страницы, а данные для них. Особенно это важно когда сайт имеет несколько версий (обычную и мобильную, или несколько разных оформлений, или мультиязычные интерфейсы).
Следует также отметить, что кэширование элементов сайта в ряде случаев невыгодно и приводит к оверхеду по потебляемой памяти кэша. Грубо говоря, вы держите в памяти не только данные, но и кучу совершенно ненужного HTML.