тестирование производительности template engines

[ONK]

я не совсем понял - ваш движок на lebowski bench на 7-10% медленее php mess?

Да, именно так. Но если подогнать данные, под потребности шаблонизатора, будет значительно быстрее.

это что за метод такой? разметили (сохранили массив указателей) а потом один раз собрали всё при парсинге?

Скорее один раз разметили, при парсинге, а при вызове add|assing собрали из кусков необходимый блок.

fixxxer, 10 - это идентификатор блока из шаблона. У меня целочисленные уникальные идентификаторы блоков.

Посмотреть не что ты хочешь? если на исходники, то пока это проблемно А если поиграть охота, могу скомпилить под что надо (если найду).

 

[fisher]

>>Да, именно так. Но если подогнать данные, под потребности
>>шаблонизатора, будет значительно быстрее
интересно "подогнать данные под потребности" означает пусть в data.inc будет ровно то что надо сетить в шаблон? если да, то понятно почему будет быстрее. но так неинтересно - это специально задумано. ичстоник данных не выдаёт данные в нужном для шаблонизатора виде.

>>могу скомпилить под что надо
so-шку, линух, ядро 2.6, php либо 4.4.* либо 5.2.* - я бы c удовольствием поигрался на досуге

UPDATE: офтоп, ONK, Вы по образованию ближе к физике или математике?

 

[fixxxer]

> 10 - это идентификатор блока из шаблона. У меня целочисленные уникальные идентификаторы блоков.

я так и думал. в принципе понятно откуда скорость, но если начать это все приводить к читабельному виду то све свалится на уровень blitz скорее всего...если не ниже

-~{}~ 21.01.08 13:17:

и кстати блок можно повторить несколько раз? (хотя при таком подходе это как раз проще)

 

[ONK]

fisher, да, но получается, что текущий data.inc заточен под ПХП и все другие шаблонизаторы заведомо проигрывают из-за необходимости перестроения данных.

Есть под win32 FreeBSD 6.2 и CentOs5 (Linux 2.6.18-8.1.14.el5)

все под ZE 2.1 и выше (пхп 5.2.4 и выше)

Моё образование одинаково далеко как от математики так и от физики По образованию я всеголишь монтажник радиоэлектронной аппаратуры. )

fixxxer,
1. Читабельности у моих шаблонов больше чем достаточно. Блоки можно располагать в любой последовательности, тем самым создавая шаблон, который можно редактировать даже в визуальных редакторах HTML кода (что конечно изврат и не безопасно с точки зрения нарушения структуры шаблона). Про ниже, поверь это не возможно Оптимальнее чем сделано там, уже просто некуда сделать (хотя зарекаться глупо ).

2. Ты же видишь, что он в цикле повторяется? -) Любой блок можно проитерировать сколько угодно раз в любой последовательности и комбинации с другими блоками. Кроме того, любой блок можно рекурсивно инициализировать в качестве переменной другого блока. Помимо этого поддерживается 2 типа пакетной инициализации (метод assign).

 

[fixxxer]

хм, ну неудобство с номерами можно решить компиляцией шаблонов из более привычной схемы <!-- BEGIN blkname --> .. <!-- END --> в циферную и генерацией набора define...
а как в такой схеме реализуется вложенность блоков?
то есть грубо говоря у меня есть dataset вида
'product' => array( // BEGIN product
'name' => 'имя',
'features' => array( // BEGIN feature
array(...) // feature первая
array(...) // feature вторая
)
);
?

-~{}~ 21.01.08 14:05:

ммм
если я правильно понял то весь шаблон бьется на подстроки "префикс"/"суффикс" между которыми вставляется либо переменная либо блок и получается этакое дерево?

 

[StUV]

интересный алгоритм
когда я пытался ради раздельного кеширования вложенных блоков сделать что-то похожее на натив-пхп - проиграл в производительности от 2.5 раз и более =)

ONK
когда код рассекретите ?

 

[ONK]

fixxxer, Я не понимаю проблемы наименования боков. У меня в АЦ есть редактор шаблонов, позволяющих редактировать блоки шаблона индивидуально. Мне в скриптах удобнее идентифицировать блоки номерами, хотя отлично вижу, что это дело привычки.

Сейчас доступен не очень красивый вариант инициализации твоей структуры данных. Но сейчас как раз работаем над более красивым вариантом Сейчас в качестве значения переменной можно инициализировать только один блок. Исправим на пакетную инициализацию.

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

 

[fixxxer]

ага, значит есть буфер, и дерево примерно вида item { char *s, int len, item * l, item * r } занятно, действительно эффективный способ

 

[ONK]

fixxxer, нет слов )

-~{}~ 21.01.08 20:32:

StUV на правокации не поддаюсь )))

 

[Alexandre]

Подробнее рассказывать нет резону

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

вообще, самым быстрым, я считал - должен быть именно pure PHP. не могу понять, почему это не так.

 

[ONK]

Alexandre, потому что структура zval не самое лучшее, что можно придумать для решения данной задачи + вынос процесса сборки блока в С экстеншен будет всегда эффективнее чем исполнение опкодов ZE.

 

[fisher]

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

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

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

 

[ONK]

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

Куда слать so-шку?

 

[Alexandre]

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

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

 

[fisher]

ONK, alexey d0t rybak AT gmail d0t com

и если можно приложите ваш вариант lebowski-bench
и если есть какая дока - тоже было бы здорово

-~{}~ 22.01.08 15:00:

>>мне интересно почему он быстрее блица
потому что смотри выше в чем отличие алгоритмически

 

[ONK]

fisher, отправил. Документации полностью соотвествующей текущему функционалу нет, да и функционал пока ещё не устоялся.

-~{}~ 12.02.08 19:46:

fisher, после внедрения кэширования в памяти, появились серьёзные архитектурные проблемы с совместимостью с ПХП 4. Так что обещание собрать экстеншен под ПХП 4 я похоже не сдержу. -(
Могу лишь выслать последнюю весию под выше пречисленые ОС и ПХП 5.2.5

 

[fisher]

>>появились серьёзные архитектурные проблемы
>>с совместимостью с ПХП 4
эээ как странно
ну что ж значит пока не судьба покрутить и потестить ваше двигло