| |
| 2.2, Антон (??), 20:36, 21/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
CTPP на порядок-два быстрее. Jinja2 на Python, а CTPP на C++ и шаблоны не интерпретирует, а как байткод выполняет. В частности CTPP используется в mail.ru на фронтэнде, да-да CTPP настолько быстр, что им на фронтэнде шаблонизируют контент, бэкенды mail.ru отдают данные в JSON.
| | |
| |
| |
| 4.4, Антон (??), 21:37, 21/06/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>"Порядок-два" - это 10-100 раз, вы уверены? оО
Вполне, если CTPP в несколько раз шаблонизаторы на Си обгоняет, то обогнать шаблонизатор на Python в 10-100 раз не проблема.
| | |
|
| 3.8, Аноним (-), 11:02, 22/06/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> не интерпретирует, а как байткод выполняет
Можно пояснить смысл этой фразы?
| | |
| |
| 4.10, dupdup (?), 12:25, 22/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> не интерпретирует, а как байткод выполняет
>
>Можно пояснить смысл этой фразы?
Шаблоны в CTPP перед выполнением компилируются в байткод. Компиляция происходит один раз, при загрузке шаблона. Соответственно, сильно экономится время на парзинге шаблонов (парзится один раз, исполняется - много).
| | |
|
|
|
| 1.7, bw (??), 06:20, 22/06/2010 [ответить]
| +1 +/– |
 Шаблоны это не то место которое требуется в оптимизации. По крайней мере в моём опыте проседание производительности даже на самых медленных шаблонизаторах было не значительным и не стоило внимания. Ну может я что-то не так делал :-).
К тому же отдельные элементы сложно-составной генерируемой страницы всегда можно закешировать, да хоть этим вашим memcache, и повысить таким образом производительность в тыщапятьсот раз, относительно постоянного использования шаблонизатора. Хотя опять же, выигрыш получается больше за счёт того же сокращения числа запросов к базе (грубо говоря).
..bw
| | |
| |
| 2.9, dupdup (?), 12:10, 22/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>в моём опыте проседание производительности даже на самых медленных шаблонизаторах было
>не значительным и не стоило внимания. Ну может я что-то не
>так делал :-).
>К тому же отдельные элементы сложно-составной генерируемой страницы всегда можно закешировать, да
>хоть этим вашим memcache, и повысить таким образом производительность в тыщапятьсот
>раз, относительно постоянного использования шаблонизатора. Хотя опять же, выигрыш получается больше
>за счёт того же сокращения числа запросов к базе (грубо говоря).
>
>
>..bw
Шаблоны - действительно не то место, где требуется оптимизация, ЕСЛИ остальная часть логики сама по себе работает медленно. Грубо говоря, нет смысла тюнить шаблонизатор, если SQL-запросы выполняются по секунде.
В случае, когда бизнес-логика работает быстро, скорость рендеринга шаблона становится одним из определяющих моментов.
Практика показывает , что лучше кэшировать не отдельные элементы страницы, а данные для них. Особенно это важно когда сайт имеет несколько версий (обычную и мобильную, или несколько разных оформлений, или мультиязычные интерфейсы).
Следует также отметить, что кэширование элементов сайта в ряде случаев невыгодно и приводит к оверхеду по потебляемой памяти кэша. Грубо говоря, вы держите в памяти не только данные, но и кучу совершенно ненужного HTML.
| | |
|
|
