Подписаться на блог
В Твиттере

Реплики и ссылки на заметки

В Фейсбуке

Ссылки на заметки

Вконтакте

Ссылки на заметки

В Телеграме

Ссылки на заметки

В Тумблере

Заметки целиком

В Же-же

Заметки целиком

По РСС

Заметки целиком

Если что-то из этого не работает, напишите мне: ilyabirman@ilyabirman.ru.

Оптимайз — 3

Пришла в голову очередная оптимизация; не понимаю пока, будет работать или нет.

e2 сейчас уже довольно прилично тормозит — иногда генерит страницу по 0,15-0,2 сек. Причина тормозов пришла откуда не ждали: очень много времени уходит на то, чтобы просто пропарсить core.php, который уже почти 200 килобайт весит. Разбивать всё это на много файлов — будет ещё больше тормозов, т. к., как мы уже проходили, сильно тормозит include. Собственно, поэтому я и стал всё собирать в единый файл.

Значит, нужно как-то сделать так, чтобы для генерации каждой страницы парсилось только то, что нужно. Но как это сделать?

Идея такая. Ведь просто тупое считывание 200 КБ не может быть долгим, так? Тормозит, потому, что это парсится всё. А что, если мы эти 200 КБ разобъем на функциональные куски (ФК), каждый из них сделаем просто строкой, но оставим в одном файле, а при вызове функции из нужного ФК, будем вместо include’а эту строку eval ()’ить? Если это сработает, то можно пойти дальше: запихать разные ФК прямо в реестр, который мы всё равно считываем. Тогда ещё на один include меньше будет.

Или ерунда? Аргументы приветствуются.

Update: Bolk говорит, eval () работает медленнее, чем include. Ну, а что ещё можно с этим сделать?
Подписаться на блог
Поделиться
Отправить
6 комментариев
Денис Панкратов
eval() однозначно медленнее.
в реестр пихать — разрушать саму концепцию. при том еще и unserialize делать ? Зачем...
Может стоит подумать а о более качественном кэше и внешней акселерации (например через mmcache или accelerator)


kukutz
Илья, надо инклюдить. Это не больно.

Просто надо инклюдить только то, что тебе надо для отработки этого запроса.

См. wackowiki.
Илья Бирман
Это больно! Всё переделывать придётся.

А хочется как-нибудь, чтобы раз — и готово :-)
kukutz
Тогда выкини половину функциональности.
Weasel
Ты уткнулся в принципиальное ограничение интерпретируемого языка программирования.

Поставить php-ускоритель или переписать всё на компилируемом ЯП ;)
Захар
0.1-0.2c это вполне нормально для твоих объёмов.
Но только при условии, что пользователь действительно нуждается во всех 200Кб отпарсенных инструкций.
По з-ну Паретто, 80% пользователей программы используют только 20% её функциональности; остальные 20% пользователей, соответственно, используют возможности программы на 80%. Поэтому для большинства действительно избыточно грузить и парсить 200Кб инструкций, из которых они реально будут использовать 40Кб.

Я бы сделал уровень «сборки» движка. При установке пользователю предлагается таблица со списком функционала (у тебя его — до рогов), из которой пользователь чекбоксами выбирает т. н. «модули», которые хочет использовать. По результатам этой формы в core.php пихается только тот код, который нужен для обеспечения выбранной пользователем функциональности. Если пользователь хочет что-то добавить или удалить, то он снова открывает эту форму и «пересобирает» движок. Точно также будет обстоять и с обновлениями. 
Илья Бирман
Это я давно придумал, просто делать не охота.
Baka
>Идея такая. Ведь просто тупое считывание 200 КБ не может быть долгим, так? Тормозит, потому, что это парсится всё. А что, если мы эти 200 КБ разобъем на функциональные куски (ФК), каждый из них сделаем просто строкой,

Где-то я такое уже видел. :-)
CGI.pm, да.
Только Штайн всё-таки не Бирман (или Бирман — не Штайн?).

Пользовательский интерфейс
Доступен первый раздел
электронного учебника

Популярное