Как определить время первой компиляции (генерации байткода) объекта PHP?

Question

[mumrum]

В мыслях крутится вот такая интересная идея, искал в интернете и собственно даже поисковый запрос в голову не приходит :)

Задача: создать объект (файл с описанием класса), который сможет настроить свое окружение (зависимости от других объектов и т.д.) при первом вызове.

Ограничения:
Объект не должен делать эти лишние проверки после первой компиляции (генерации байткода).

Т.е. получается следующее:
Пишем объект рассылки писем MyMail, который способен отправлять разными способами. В конструкторе проверяем, был ли он скомпилирован или взят байт-код из кэша.

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

Есть варианты конечно:
в режиме отладки проверять постоянно окружение, а в продакшн - не проверять,
проверять наличие конфига, ( а если файл класса изменился? ) и т.д.
но хотелось бы универсальности... думаю, источник байт-кода как раз был бы отличным "флажком"
any ideas?

Answer 1

[Сергей Протько]

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

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

Посмотрите как это реализовано в symfony - в тамошней реализации dependency injection container есть компиляция контейнера. Так же стоит обратить внимание на PHP-DI, который умеет сам себя настраивать (на основе рефлексий и аннотаций) и может использовать кэш (на базе doctrine/cache, так что в dev окружении обычно ArrayCache используется, а в продакшене что-то вроде ApcCache). Узким местом в таких системах обычно является именно настройка через аннотации.

p.s. Я не до конца понимаю вашу идею и чего вы хотите добиться. Из описанного вами прироста производительности не будет, а все кэши и прочее должны вармапиться не при первом вызове, а при деплоее приложения. И что значит "создаем файл конфигурации"?

Comments

[mumrum]

Я думаю это имело бы место именно в сторонних компонентах(скопировал и забыл, какой нибудь псевдо MyMail), т.е. они получают возможность "инициализироваться" и потом не производят лишние проверки. Но т.к. такого я не наблюдал нигде, то и вопрос просто возник на стадии "а если".

[Сергей Протько]

@mumrum, смотрите в сторону dependency injection. Настроил сервис один раз, и потом используешь. То что вы описываете попахивает каким-то извращениями.

[Сергей Протько]

@mumrum, если для вас главное минимизировать время инициализации, в контексте компонентов аля MyMail оно ничтожно. В крайнем случае можно воспользоваться каким популярным DI контейнером, который умеет компилить всю инициализацию, но по опыту скажу что разница во времени выходит незначительной.

Answer 2

[Виталий Желтяков]

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

Answer 3

[mumrum]

Нашел нужную информацию в apc_cache_info(), однако доставать её довольно накладное дело. Возможно есть еще способ :)

Comments

[Сергей Протько]

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

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

[Сергей Протько]

При первом вызове можно генерить прокси, а там уже будет использоваться именно она, и не нужно никаких проверок.