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

[tony2001]

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

Не хами.
Если ты не понял мои простые слова, я могу перефразировать: твои некомпетентные наезды никого не впечатляют.
Пишите дальше, Сеня.

 

[fixxxer]

tony2001
не, я в том смысле, почему в blitz коллбэки медленнее, чем в pure php. Насколько я понимаю, call_user_function_ex это оно и есть

 

[fixxxer]

Ну, это уже не по теме тормоза, просто тогда же выяснили, что блитц еще и дыряв. Пишу в переменную класса с хелперами значение А, вызываю шаблон, вывожу на экран переменную - а там случайный мусор из памяти. Потенциальная дырка. С каким-то другим экстеншеном я такие дыры находил и показывал вызов Win API функции напрямую из пхп кода .-)

Это http://www.blackhat.com/presentations/bh-usa-09/ESSER/BHUSA09-Esser-PostExploitationPHP-SLIDES.pdf видимо, тут проблема на уровне самого php и она давно исправлена

 

[Push_Ok]

> а заявление DiMA голословно. т.е есть реально пример когда блитц работает медленние того же смарти?
При наличии в шаблонах большого числа хелперов, переключение исполнения между блитцом и пхп создавало тормоза.

вот вызов php кода из блитца не делал не было смысла в этом, те в шаблонизатор данные приходят уже готовые. Да шаблоны простые.
+ в шаблоны подставлятеься fetch из других шаблонов. но я не думаю что разница между вызовом ексенсиона заметна когда это выполняеться много раз. иначе бы сам по себе процесс mysql->query без учета базы тормазил. или например использование мемкеша как memcached.so

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

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

 

[fisher]

Граждане.
Так вышло.
Большинству оказался нужен смарти-на-стероидах.
Не могли бы вы переписать смарти на Си, спрашивали вы на форумах.
А мне была нужна простая хрень замена php_templates.
Насчет логики - да, вам это нужно. Я стал это добавлять - не бросать же проект. Но у меня просто нет времени. Знаете Си, хотите помочь - пишите. Осталось чуть-чуть, грамматически блиц уже разбирает выражения в if/unless, осталась поправить экзекьютор.
Про call_user_func.
Я сам был в ярости - ведь весь прикол был в расширяемости.
Ну такая вот хрень вышла - действительно переключения в пхп-машине медленные.
Я не разбирался, почему - и я вряд ли смогу на это повлиять (хотя это, наверное, интересная задачка).
Не используйте колбеки, если у вас жесткий хайлоад и на фронтах проц - узкое место.
И это кстати написано в доках блиц.

 

[grigori]

помню, фиксер как-то привел интересный дамп, из которого можно сделать вывод, что lambda-функции исполняются через eval

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

 

[fisher]

Нет, иначе, Тони может сказать подробности. Внутри пхп-машины замороченный метод звать метод. Тут АнТоХа предложил генерить байткод, мол, в таком случае нет этих переключений, и это кстати интересно, поскольку автоматически позволит использовать акселерацию. Но это на корню ломает всю, блин, идею - надо было тогда просто писать кодо-генератор на похапе как смарти.

 

[~WR~]

Раз зашел этот разговор, задам вопрос, который давно интересует.

Скажите, вызов метода таким образом:

$method = 'get_' . $key;
$this->$method();

Чем-то отличается от call_user_func в недрах php?

 

[fisher]

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

 

[pilot911]

этим и хорош ПХП

 

[fixxxer]

fixxxer@mbp ~$ time php -r 'for($i=0;$i<1000000;$i++)call_user_func("htmlspecialchars","");'

real	0m1.251s
user	0m1.232s
sys	0m0.013s
fixxxer@mbp ~$ time php -r '$f="htmlspecialchars";for($i=0;$i<1000000;$i++)$f("");'

real	0m0.600s
user	0m0.585s
sys	0m0.012s
fixxxer@mbp ~$ time php -r 'for($i=0;$i<1000000;$i++)htmlspecialchars("");'

real	0m0.352s
user	0m0.335s
sys	0m0.013s

 

[fixxxer]

генерить байткод

он и из пхп кода прекрасно генерится
задача оптимизировать кодогенератор смарти какого-нить куда проще генерации байткода руками, мне кажецо

UPD
или, хм, как-то генерировать байткод только для коллбэков который грубо говоря загонять в соответствующий этап eval()? хм

 

[varan]

Я смотрю опять шаблонизаторосрач. Старая добрая традиция phpclub'а

 

[grigori]

ух ты, $f() в 2 раза быстрее, чем call_user_func

 

[DiMA]

> Пишите дальше, Сеня.

Это твоя показушная осведомленность внутренностями пхп никого не впечатляет, ибо знание этого не дает никому (кроме разрабов пхп) ничего ценного, не избавляет от тормозов, не решает проблемы топика и т.д.

> real 0m1.251s
> real 0m0.352s

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

 

[AmdY]

надеюсь никто не собирается переходить на личности.

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

 

[fisher]

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

 

[Ирокез]

хз. но мне так кажется, что при нагрузке к примеру 800 rps (native php + eaccelerator), 10-15% которых дадут использование blitz особой роли не сыграют (если не брать частные случаи)
ключевым моментом использование шаблонизаторов, наверное является простотой и понятный синтаксис и уменьшение избыточности(увеличение читабильности) исходного шаблона.

когда-то был написан на заказ шаблонизатор, перекрывающий по тестам blitz, но синтаксис и размазывание использование шаблонов, просто убивало

(мифическое наследование шаблонов, о котором кричат на каждом углу просто потрясает )

 

[fisher]

15% cpu на вебах сыграют, если в кластере вебов сотни машин а что не так с наследованием, почему оно мифическое и потрясает?

 

[Ирокез]

15% cpu на вебах сыграют, если в кластере вебов сотни машин а что не так с наследованием, почему оно мифическое и потрясает?

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

честно говоря (извините что ссылаюсь на свой опыт), но я не встречал проектов где было-бы архи важно (да чего-там даже важно) использование наследование в шаблонах, прекрасно задачи решались и без этого "модного" тренда