Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111970
MIME-Version: 1.0
References: <ME2P282MB02272021544EFDBE6BF44A23F2300@ME2P282MB0227.AUSP282.PROD.OUTLOOK.COM>
 <940131FA-19B3-406C-8982-0AD276FD1879@gmail.com>
In-Reply-To: <940131FA-19B3-406C-8982-0AD276FD1879@gmail.com>
Date: Thu, 1 Oct 2020 14:30:28 +0200
Message-ID: <CAF+90c8y6dpqMg8s+X-ndQwp52CDL7Q9oHL_DwDQ1OS-k1GR9w@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005dfce905b09b2f42"
Subject: Re: [PHP-DEV] RFC: execution opcode file without php source code file
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000005dfce905b09b2f42
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 1, 2020 at 1:44 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> Hi,
>
> On 1 October 2020 10:36:20 BST, "=E8=82=96 =E9=91=AB=E9=91=AB" <chopins.x=
iao@live.com> wrote:
> >I commit a new request path, the request is about execution opcode file
> >without php source code file
> >this RFC provides similar to class file of java and pyo file of python.
> >patch is: https://github.com/php/php-src/pull/6146
>
> I'm sure someone who knows the internals better can clarify, but my
> understanding is that PHP OpCodes don't currently have any stability
> guarantee, so you can't rely on a binary taken from one version will run =
on
> another, even within a release.
>
> In order to be useful, this will therefore need two things:
>
> - a header in the file identifying the engine version it was compiled for=
,
> with an error raised on any mismatch
> - a policy of how to manage that version number, and how users can know
> which versions their binary files will work on
>
> There's probably a limit to how stable we can (or want to) make the VM, s=
o
> these files will never be as portable as a Java class file or .Net assemb=
ly.
>

This is correct. PHP uses the "system ID" to determine whether it is
possible to reuse compiled opcodes. This system ID is used by the existing
file cache.

The linked pull request however explicitly disables this check, which is
not safe. And with that check enabled, this feature would probably have
limited usefulness, as the cached file would be bound to a specific PHP
patch release (and to some degree to which extensions are loaded).

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=
.

Regards,
Nikita

--0000000000005dfce905b09b2f42--