Объясните, плиз, на пальцах механизм торможения Смарти

[Фанат]

Объясните, плиз, на пальцах механизм торможения Смарти

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

Как я понимаю, вся загогулина в том, что надо проверять валидность скомпилированного шаблона? Именно здесь, как я понимаю, может быть торможение?
И самая большая засада здесь - вложенные шаблоны. так?
Неужели этот механизм в смарти настолько неоптимален, что сводит на нет все преимущества "чистого пхп" в шаблонах?

 

[donflash]

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

Лично я +1 за Smarty и +2 за XSLT

 

[Фанат]

Спасибо за ваше мнение, но прошу воздержаться от оффтопика, и особенно - от голосований. Я задал вопрос не о том, кто на чём пишет.

 

[itprog]

Smarty изначально неплохо оптимизирован, ничего лишнего не создается, не загружается когда это не нужно.
В основном причина увеличения времени генерации страницы это некоторые конструкции для обратной совместимости и выполнение исходного кода smarty (не шаблонов) Zend-ом...
Именно поэтому во всяких smarty light и отрезают всякую не очень нужную функциональность.

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

Да, по производительности Savant3 (который использует для шаблонов язык php) и smarty 2.6.х одинаковы.

 

[Найч]

2 момента, в которых были замечены временные потери:
- include плагинов (как нативных, так и custom), а они лежат в отдельных файликах. Хоть смарти инклудит только то, что используется в текущем шаблоне, это не отменяет инклуд "по-файлово"
- генерируемый код несколько неоптимален. Много лишних движений для обеспечения нужной функциональности. Например - чтоб не перетирались переменные при инклудах, идет сохранение состояния до и восстановление после.

Даже используя оптимизаторы разница между native php and smarty весьма заметна. И чем сложнее шаблон - тем больше

 

[Фанат]

спасибо

 

[crocodile2u]

Инклюды компилируются смарти в ... инклюды Это минус для производительности, которого, кстати, удачно избегает WACT.

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

Сейчас уже не помню, но у меня были и другие претензии к смарти.

 

[alexhemp]

Вот тут есть тест различных шаблонных движков

http://test.country-info.ru/bench/

Можно видеть - что Smarty - не тормозит.
Безусловно замедление есть, если сравнивать с "чистым" php - но в 99% случаев оно оправдано возрастанием скорости разрабтки (для чего впрочем и нужны сторонние библиотеки вообще).

 

[Фанат]

тесты от дяди меня интересуют в последнюю очередь

 

[itprog]

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

crocodile2u
замечания надо было на форум smarty сразу, там разработчики все реквесты читают и отвечают, разжевали бы почему так и может бы пофиксили

 

[Rammstein]

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

 

[fisher]

1) то, что компилит смарти - это куча говнокода, см. пример.
http://raa.livejournal.com/62530.html#cutid1
этот код мягко говоря неоптимален.
2) если ему нужно много инклюдов - тоже нехорошо
3) если в какой-то момент он решает что надо что-то перекомпилить, производительность даже при малой нагрузке может просесть на порядок - а чем это закончится при нормальной нагрузке вообще хрен знает

 

[itprog]

Rammstein
Вот и пиши изначально в PHP, увеличивая тем самым, как уже выше говорили, время разработки приложения.
Компиляция проходит только один раз, дальше о ней надо забыть, компилятор smarty вообще не запускает.
Да и топик не об этом...

 

[fisher]

2alexhemp
ОФФТОП: http://test.country-info.ru/bench/
этим тестом для оценки производительности пользоваться плохо. там очень простые тесты, советую ознакомиться с методикой

 

[itprog]

fisher
Код лично мне тоже не нравится, но не кажется что его можно сгенерировать оптимальнее, не потеряв весь функционал. Иначе это бы уже кто-то сделал

обсирает каждый, нормальную альтернативу никто не предлагает. Всевозможные движки на c++ (может сразу тогда всё на c++ делать?) да, быстрые, но при разработке общедоступной cms/cmf использование таких шаблонизаторов убивает продукт...

про 3) пункт интересно, в какой момент он решает перекомпилировать?

 

[alexhemp]

Фанат

Заданный тобой вопрос - религиозный, либо веруешь, либо нет

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

Решения обладающего таким-же функционалом что и Smarty и при этом более быстрого просто нет, поэтому вопрос некорректен

 

[Фанат]

itprog
на редкость не в тему реплика. ты бы хоть обратил внимание - кому пишешь

-~{}~ 15.01.07 15:24:

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

Я, кажется, ясно описал вопрос. у смарти, ТЕОРЕТИЧЕСКИ скорость должна быть выше, чем удругих шаблонизаторов. потому что, ТЕОРЕТИЧЕСКИ, он не должен выполнять свою работу. За него должен работать чистый пхп-код.

НО, раз ОБЪЕКТИВНАЯ РЕАЛЬНОСТЬ говорит нам, что смарти тормозит, я спросил о причинах.

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

 

[itprog]

Фанат
как и любая программа smarty требует время на компиляцию и выполнение, каждый будет не рад когда запятая во времени уедит вправо на несколько позиций и причину назовет "тормозом".

Всё. Очередной топик ниочем... Вместо причин будут искать всякие косяки.

Кому пишу вижу, потому и заговорил там об этом.

 

[Фанат]

itprog

нормальную альтернативу никто не предлагает

ты не в курсе, что фишер альтернативу предлагает?
или просто решил язык почесать для красного словца?

Вместо причин будут искать всякие косяки.

если ты не заметил, здесь изложили причины. причем - без истерики, которую ты здесь устраиваешь.

 

[itprog]

я объяснил почему предлагаемая альтернатива не "нормальная" для меня.

можно поинтересоваться что ты будешь делать с изложенными причинами?