Как стать автором
Обновить

Комментарии 7

Возможно я ошибаюсь, так как я с PHP очень мало встречался, но разве PHP сам не является текстовым шаблонизатором?

Зачем тогда накладывать ещё один поверх него?

Занимательный факт: если использовать KPHP, а не PHP, то подгрузить новый шаблон или изменить существующий без перекомеляции будет очень проблематично, ведь эти PHP-скрипты станут частью бинарника.

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

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

Я немного расширил статью. У меня спросили, почему в исходниках KTemplate используются phpdoc комментарии вместо тайпхинтов. Ответ в том, что тайпхинты в этом случае могут вызвать измеримое замедление (цифры приведены в статье). Для KPHP разницы, откуда брать информацию о типах, нет, поэтому типизацию я проверяю при компиляции в KPHP, а при запуске на PHP считаем, что проверять типы уже не нужно, пусть в рантайме хотя бы немного быстрее будет работать. Быстрее Twig для PHP оно всё равно не будет, но по крайней мере отставание можно сократить.

Ещё добавил опции JIT, использованные для бенчмарков. Я пробовал opcache.jit=1235 и некоторые другие комбинации, но on оказался лучше всех. Считаю, что это оптимальный и разумный default.

Интересно. Как я понимаю, шаблонизаторы обычно "материализуют" весь шаблон, и отдают целиком. Не уверен насчет PHP, но в некоторых веб-фреймфорках (в т.ч. подражающих nodejs) для других языков существует возможность стриминга чанков вывода с их асинхронной отправкой под капотом. Так вот, не станет ли сервер быстрее, если шаблонизатор вместо материализации (с конкатенациями и/или стрингбилдерами внутри) будет просто передавать чанками текст из узлов шаблонизатора в асинхронную отправку? Вроде, кроме случая когда есть множество узлов дающих текст малой длины проблем быть не должно, но и их буферизовать можно.

Идея интересная, я не сталкивался с такими решениями.
Возможно потому что никогда не генерировал из шаблонов мегабайты данных.
Обычно даже десятки вложенных шаблонов создают относительно скромные объёмы текста.

В целом можно сделать возможность потоковой обработки результатов шаблонизации. Вопрос в том, где эти точки передачи данных вставлять. Если слишком часто - будут какие-то мелкие куски и высокий overhead на эту логику. А вообще было бы любопытно на каких-то больших объёмах глянуть, будет ли там прирост скорости или нет. Потому что для средних шаблонов я почти уверен, что писать всё в строку будет быстрее.

Потому что для средних шаблонов я почти уверен, что писать всё в строку будет быстрее.

Вполне возможно. По идее, если буфер изначально достаточно большой, чтобы вместить результат шаблонизатора, то оверхед минимальный. Проблема возникает, если буфера вообще нет (конкатенация в языках с иммутабельными строками без стрингбилдера), или если он переполняется, и нужно выделить буфер большего размера, и скопировать туда все из первого, возможно даже несколько раз, и так в каждом потоке обработки запросов.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий