Pull to refresh

Comments 16

[PR] OPCache: Direct execution opcode file without php source code file

Так это и сейчас можно, правда чуть менее удобно. Если не путаю, за это отвечает настройка opcache.file_cache, которая будет использовать файлы опкеша, вместо shmop.

Там, судя по всему, имеется ввиду подключение аля dll или so.

Речь про запуск скомпилированного в опкод. А-ля .java -> .jar
К сожалению не получится, поскольку


Формат опкода в PHP нестабилен и несовместим от версии к версии.

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

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

И чем оно тогда концептуально будет отличаться от прелоада?

Исходники в контейнере вообще не нужны (от реализации зависит, правда, но логично чтоб были не нужны) и скрипта инициализации не нужно, как и времени на "разогрев" при старте сервера.

Кстати, с привязкой к конкретному коммиту на конкретной архитектуре можно не то, что опкоды, а нативные для "JIT" компилировать заранее

А можно вообще слепок памяти взять :)

Это так. Однако повторю мой тезис: Файлы и сейчас можно сгенерировать и запускать.


Единственное отличие от представленного RFC это то, что запуск их происходит не напрямую (пхп выполни мне файл опкода), а опосредованно (пхп выполни код Х или возьми его из директории, если там есть файлы опкеша для этого кода Х).


P.S.

Не знаю насколько это будет интересно, но я набрасывал пример ридера таких файлов: https://github.com/SerafimArts/opcache В данном случае example.php является примером PHP кода, а example.php.bin, бинарным файлом опкеша, сгенерированным самим PHP для этого example.php. Там же есть набросок исходников для чтения файлов опкеша, а в resources висят шаблоны для деструктуризации файлов опкеша PHP для 010 Editor, что б понять что в них вообще находится.

Это так.

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

В том-то и дело, что мизерный, скорее всего.

Отсюда возникает вопрос — а какая, собственно, цель?


Вот аргументация автора


This patch addresses the following issues:
  1. Opcode binaries can be published when binding to a PHP interpreter (version dependent) release product, rather than just the PHP source code(for example, JAVA and .NET is version-dependent)
  2. Extend compilation only online to compile anywhere. You can avoid problems caused by cold starts by publishing more code


Explanation of some questions:
This patch simply changes OpCache's process of detecting the opcode cache against the requested file, allowing it to treat the current file as an Opcode file..
This means that files compiled using the opcache_complie_file function are still cache files that can be moved anywhere, so it is up to the developer to ensure that the compilation is consistent with the version of the interpreter that is running.
When a developer compiles with the opcache_complie_file function and enables the relevant configuration in the running container, they should be aware of these limitations and some of the functionality failures.
I will add PHP version information when writing labels, and give a hint when the runtime does not match the current version.

In addition, the Phar file does not skip the compilation of Opcache, so it also supports packaging opcode files into the Phar file

На вот этот вопрос Никиты


It would be good to know what the actual use-case for this is. If the goal
here is to distribute pre-compiled PHP code without the source code, then
this is not going to work without making the opcode format stable (which, I
think, is pretty unlikely.) If the goal is improving cold startup
performance, then I wonder what the benefit over the existing file cache is.

По первому варианту использования, AST может выстрелить, так как оно сильно стабильнее самой VM (в плане обратной совместимости).

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

Эффективность аховая. Но речь то больше про обфускацию, насколько я понял.


Но генерация опкода из AST всяко быстрее. Токенизация вообще не самый быстрый процесс, а там еще и проверка на валидность.

Sign up to leave a comment.

Articles