Размышления о шаблонизаторах

[@Bal]

>Получилось, что используя резкие как понос нативные шаблоны весь выигрыш в скорости просирается буфферизацей.

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

Мне так кажется, что ты немного не в теме. Потому что буферизация не «просирает» выигрышь, а, наоборот, позволяет его сохранить.

Итак, тест. 100 отдельных выводов строки по 100 байт (итого — 10кБ) через echo и один общий после стократного суммирования строки:

out_echo_multi: 0.000110864639282
out_echo_one: 0.00011420249939

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

А что на счёт чистого непарсеного HTML? В смысле ?>some some some<?

Получается так:

out_php: 0.000123977661133

>Очень повеселила проблема того же хабраюзера с медленной работы ob_start().

Тоже всё относительно. Да, скорость снижается в 9 раз:

out_ob_multi: 0.000921010971069
out_ob_one: 0.000912189483643

Но это мизер на общем фоне затрат на инициализацию PHP-процесса и внутренние процессы. Упомянутый скрипт работает в течении… (запускаю ab) 50мс.

Так что даже ob_start обрабатывается только в течении 1/50 всего времени. Даже десятком ob_start вызовов можно пренебречь на фоне пустого скрипта. Если же он у нас будет полноценный, с работой с БД, обработкой результатов и будет выполняться хотя бы 0,1 сек — то эта проблема вообще не встаёт.

…

Сорец скрипта лежит на balancer.ru/test-out.php.txt, результат работы — balancer.ru/test-out.php

[@Bal]

Да, вдогонку. Естественно, что при выкачивании wget'ом с лимитом скорости в 1кБ (качается 50 секунд) цифры не меняются. На то она и буферизация. А уж отключать её для теста — извините, у меня этот сервер сейчас по 1,3млн хитов в сутки отбивает :D

[@fuse]

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

[@tenshi]

ей нельзя воспользоваться после перехвата фатальной ошибки и, как следствие, сформировать красивую страницу с сообщением об ошибке, навигацией, блек-джэком и шлюхами =)

[@Bal]

Э… Не поняю. Как это нельзя? :) Как раз с ней-то и можно. В смысле, что хедеры можно выводить вперемешку с echo.

В общем, ограничений только меньше, чем без буферизации :D

[@tenshi]

а ты попробуй =) пхп выдаст ошибку «нельзя инициировать буфферизацию вывода в обработчике буфера вывода» или как-то так.

ты видимо не читал: dklab.ru/chicken/nablas/45.html

[@Bal]

>нельзя инициировать буфферизацию вывода в обработчике буфера вывода

Естественно, нельзя. Но какое это отношение имеет обработке ошибок и к буферизации вывода сервером? Это совершенно разные буферизации :)

>ты видимо не читал: dklab.ru/chicken/nablas/45.html

Посмотрел. Зачем мне перехватывать фатальные ошибки? У меня в нормальном коде их просто не бывает :)

[@tenshi]

* упёрлись в ограничение по памяти или по времени выполнения
* не учли зависимость при рефакторинге
* не проверили тип какого-то параметра
список можно продолжать…

и не надо рассказывать байки, что ничего не забываешь и всё учитываешь…

[@Bal]

> dklab.ru/chicken/nablas/45.html

Прочитал, наконец.

Красиво, всё равно не обработаешь ошибку: «Вы увидите, что PHP отобразил стандартное сообщение об ошибке, но к нему в конец было приписано " — output is handled!", т.е. наш обработчик сработал.»

Так что уж проще потенциально проблемный код eval'у скармливать. Хоть мусора на экране не будет.

[@tenshi]

я обрабатываю красиво ;-) у меня просто приложение не занимается «выводом в браузер» — оно формирует некую «результирующую структуру». а в обработчике вывода — простая проверка: если кто-то что-то вывел самостоятельно — значит это ошибка. если ошибки нет — результирующая структура сериализуется и выводится в браузер.

eval не поможет от всех фатальных ошибок — только от ошибок парсинга

[@fuse]

Какие нафик фатальные ошибки в шаблонах? У нас вообще-то речь шла исключительно о шаблонизаторах.

[@tenshi]

а кто сказал, что фатальная ошибка возникла в шаблоне?

[@fuse]

Ну тогда похоже вам просто захотелось с умничать по поводу перехвата фатальных ошибок.

[@tenshi]

нет, похоже вы не умеете читать.

[@developer]

о! на меня тут ссылаются а не позвали!

топ habrahabr.ru/blogs/php/45258/
не имеет отношения к нативным шаблонам.

а насчет «очень повеселила», так ведь вы сами не понимаете эту проблему ибо не сталкивались с ней.

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