On Thu, Oct 1, 2020 at 1:44 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> Hi, > > On 1 October 2020 10:36:20 BST, "肖 鑫鑫" <chopins.x...@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, so > these files will never be as portable as a Java class file or .Net assembly. > 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
