Pull to refresh

Comments 16

способ определения "что же у нас из зенда тащится в проект" явно далёк от идеала :).
почему не использовали tokenizer?

да и какая-то каша у вас в примере. То ZendCompiler, то ZendMake. Тем более нету ZendCompiler::make() :).
пока писал заметку, кое чего поменял.
исправил
чтот то недоступен сервер. http://www.mocksoul.ru/

все хотел посмотреть этот пример(еще из статьи про оптимизацию) - но скипт выдает тока пхп код.
там вообще впринципе мало что понятно. Но можно выдрать extract_good_source() (убивает require, комментарии, whitespace левый... :)

принцип - запускать через бразуер, чтобы был доступ к APC (статистика по загрузке файлов тащится оттуда). В проекте уже это портировано с APC на XCache - если надо, могу выложить (почти тоже самое в общем-то). Так вот. Смотрит в xcache/apc по файлам. Находит те у которого больше всгео запросов. Считает их как выполняющиеся "всегда". Затем у остальных файлов выстраивает процент - сколько типа грузится. Рисует табличку на экране и красным показывет те новые штуки, что он выбрал но в массиве autoloadfiles не обнаружил. Берём файлик и руками пишем в autoloadfiles. Перезапускаем скрипт с ?SAVEFILE и он всё соберёт. Just for example.
посмотрел на ваш скрипт.
не использовал tokenizer потому, что не знал о нем )) но, на мой взгляд регулярками нагляднее и короче)

способ определения файлов для сборки может быть совершенно любой. Можно собирать отдельно ZF и отдельно файлы приложения. Можно ZF помодульно, пофайлово или в зависимости от APC-попаданий. Можно все вместе. По вкусу.
Смысл есть. Спасибо за идею и реализацию.
Уупс. Предложенный класс неправильно обрабатывает комментарии, точнее — принимает за комментарии то, что ими не является. Например, Zend_Locale_Data строка 162:
if ($newpath != '//ldml') {
после // код обрезается.
да с комментариями действительно проблемы. В Zend_CAche вырезаются строки типа $this->method('php://');
Нужно либо вырезать комменты с начала строки, либо действительно исползьовать токенайзер.
Мои реглярки после исправления выглядят так:

$pattern[] = '%(^\$)%';
$replacement[] = '';
$pattern[] = '%^\s*#.*%m';
$replacement[] = '';
$pattern[] = '%/\*.*?\*/%sm';
$replacement[] = '';
$pattern[] = '%^\s*//.*$%m';
$replacement[] = '';
$pattern[] = '%(require_once|include_once|require|include) [("\'](.*?)[)"\'];%';
$replacement[] = '';
$pattern[] ='%^\s+$%sm';
$replacement[] = '';
$pattern[] ='%(\n){2,}%';
$replacement[] = "\n";
да и в Zend_Cache есть еще проблема. Там подключаются Zend_Backend и Zend_Frontend в зависимости от переданных параметров. Вырезать их подключение автоматически не удастся. Остается только подключать их как обычно и исключать из сборки
Здравствуйте. :) Писал в прошлом такую вещь на основе tokenizer, в итоге, не понравилось. Советую взглянуть в сторону PHC, там есть очень интересный туториал: http://www.phpcompiler.org/doc/tutorial6…, на основе которого можно построить такую систему. Жаль, что все преимущества ручного труда начисто элиминируются акселераторами. По крайней мере, у меня при включенном Xcache с отключенной проверкой модификаций разницы между производительностью собранного и обычного проекта нет.
у меня разница при xcache даже с выключенной проверкой модификации файлов - трёхкратная. Инклудится примерно 140 файлов (т.е. собираются в один).
я заметил интересную вещь: чем больше файлов инклюдится, тем бесполезней становится кешер (в моем случае APC). Время выполнения увеличивается, но не критично.
Разница есть! У меня к примеру в 3-4 раза производительность стала выше!
Ни у кого случаем нет актуальной версии?
Sign up to leave a comment.

Articles