Проблема оптимизации алгоритма шаблонизатора.

Sardonix

Новичок
Проблема оптимизации алгоритма шаблонизатора.

Я заморочился созданием шаблонизатора, и, после некоторого времени, выдал следующий алгоритм:

1)Шаблон index.view построчно считывается методом validate() класса pattern: в каждой строке ищутся псевдотеги, имеющие формат ###<содержимое_тега>###. Все найденные псевдотеги помещаются в массив.

2)Массив псевдотегов обрабатывается следующим образом: для каждого элемента проверяется, присутствует ли соответствующий модуль-обработчик(в моем случае это - класс), если присутствует - создается экземпляр соответствующего класса, который выполняет нужные действия и помещает результат в массив; вместе с результатом в массив помещается название модуля-обработчика, который этот результат сгенерировал.

3)Массив результатов передается в метод exchange() класа pattern и здесь происходит следующее: снова построчно считывается шаблон index.view, в каждой строке ищутся псевдотеги; когда псевдотег найден, он сравнивается с названиями модулей-обработчиков, переданных в массиве результатов - если псевдотег совпадает с названием модуля-обработчика, то он[псевдотег] заменяется на тот результат из массива результатов, который соответствует совпавшему имени модуля-обработчика.

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

Нельзя ли этот алгоритм как-нибудь оптимизировать с целью повыщения скорости его работы?
 

Wicked

Новичок
я так понял, что view не "компилируется" в PHP-код, правильно?
 

Sardonix

Новичок
Автор оригинала: Wicked
я так понял, что view не "компилируется" в PHP-код, правильно?
View - это HTML-код со вставками в нужных местах псевдотегов.
Парсер преобразует его так: читаем строку, если в ней псевдотегов нет - сохраняем ее как есть в виде элемента массива; если псевдотег есть - обрабатываем его (смотри начало нити), а потом заменяем на результат обработки и эту - обновленную - строку сохраняем в виде элемента массива. После всего этого выводим все элементы массива. Т.к. страница, получившаяся из view, формируется выводом всех элементов массива при помощи print, то можно сказать, что view в РНР-код все-таки переводится.
 

Shturm

Гигант мысли
Sardonix
Лучше реализуй компиляцию, например, как в смарти -
преобразуй обработанный хтмл в пхп-код, который сохраняй в файл.
А этот файл, если не истек срок его валидности - подключай в будущем - вместо обработки шаблона. И так - по одному пхп-файлу на шаблон.
А то убъешь сервер;) А если даже не убъешь, то покалечишь;)

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

Sardonix

Новичок
Автор оригинала: Shturm
Sardonix
Лучше реализуй компиляцию, например, как в смарти -
преобразуй обработанный хтмл в пхп-код, который сохраняй в файл.
А этот файл, если не истек срок его валидности - подключай в будущем - вместо обработки шаблона. И так - по одному пхп-файлу на шаблон.


Да и вообще - какой смысл каждый раз парсить шаблон, если после первого же прохода мы точно знаем, в каком месте хтмл должна вызываться команда пхп.
Мысль твою понял - создать некий кэш страниц. Действительно, если парсинг уже произошел, нет смысла повторять его - результат будет таким же, но это только в том случае, если шаблон не претерпел изменений. А как быть если дизайнер его подправил? Поэтому если кэш и делать, то нужно, чтобы в качестве параметра валидности выступало не некое время жизни - срок валидности - , а состояние шаблона. Нужно каким-то образом проверять его на наличие изменений. Возникает вопрос - каким способом это сделать?
Что же касается Smarty - я повтыкал в систему и ничего не понял, а разбираться с кодом, который написан не тобой самим и слабо комментирован, нет никакого желания. Есть , конечно, достаточно полная документация по Smarty, но это документация , ориентированная в первую очередь на ИСПОЛЬЗОВАНИЕ системы, а не на внесение в нее изменений.

А то убъешь сервер;) А если даже не убъешь, то покалечишь;)
- поясни, пожалуйста, этот момент.
 

Shturm

Гигант мысли
Sardonix
Алгоритм записи кеша я привел практически полностью;)
Ну, т.е, например, строка в шаблоне <div>###TEMPLATE_VAR###</div>
превращается в что-то вроде <div><?$this->TEMPLATE_VAR?></div> и в таком виде записывается в кеш, который в будущем подключается внутри шаблонизатора по include();

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

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

Хотя на моей памяти сам апач не разу не падал из-за черезмерного пожирания ресурсов. Падала только MySQL;)
 

Sardonix

Новичок
Автор оригинала: Shturm
Sardonix
Алгоритм записи кеша я привел практически полностью;)
Ну, т.е, например, строка в шаблоне <div>###TEMPLATE_VAR###</div>
превращается в что-то вроде <div><?$this->TEMPLATE_VAR?></div> и в таком виде записывается в кеш, который в будущем подключается внутри шаблонизатора по include();

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

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

Хотя на моей памяти сам апач не разу не падал из-за черезмерного пожирания ресурсов. Падала только MySQL;)
Немного прояснилось. Спасибо. Сейчас буду в это втыкать.
 
Сверху