Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89213
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.217.174 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <12.A1.62946.CB756465@pb1.pair.com>
References: <12.A1.62946.CB756465@pb1.pair.com>
Date: Fri, 13 Nov 2015 20:43:59 -0800
Message-ID: <CAESVnVoC1PJM5hZbKs=3WWHyqsmc=j4N=XcZXgDBkNx4jTwEwA@mail.gmail.com>
To: Stephen Coakley <me@stephencoakley.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Support for writing and executing compiled opcode
From: pollita@php.net (Sara Golemon)

On Fri, Nov 13, 2015 at 1:35 PM, Stephen Coakley <me@stephencoakley.com> wrote:
> I've been thinking about PHP optimization and distribution, and I would like
> to hear some opinions on introducing a new feature for a future PHP 7
> version. Here's the concept: allow PHP opcode to be both saved after parsing
> a file, and to be loaded and executed, similar to the bcompiler extension
> and the APC bin functions back in the day.
>
Back up.  What problem are you /actually/ trying to solve?  OPCache
does a very good job of caching the result of compilations, and it's a
standard, bundled extension in common use.  Is there a hit for that
first load? Yes, but webservers run a very long time, and a priming
step during deployment is more robust that pushing pre-compiled script
databases.

> The advantages are clear: libraries and applications could be compiled to
> opcode ahead of time so PHP wouldn't have to compile it again and again
> (assuming you're not already using OPcache).
>
That's a REALLY strange assumption to make.  Who runs a PHP site where
performance is any kind of concern, but doesn't use OPCache?  Are
these hypothetical people going to fail at that, but succeed at adding
an additional step to their deployment process?  That seems unlikely.

> A new function could be provided to parse a PHP file, but instead of
> executing it, the compiled opcode would be saved to a file. It might part of
> the OPcache extension if it makes sense, and could be called
> opcache_compile_to_file() or something.
>
I'm not inherently against this as a concept, but again I have to ask:
"What problem does this solve?" because it certainly creates a new
one.

Here's my guess: You want to be able to distribute a library or
application without giving your users source code.
Apart from being a very non-open thing to do, it's also pointless.
Disassembling an opcode stream to PHP source code is trivial.  Many
folks have tried to "encrypt" such bundles, and they've all been
broken, because eventually PHP has to be able to see the bytecodes.

Or am I wrong, and there's a motivation I'm just not seeing?

-Sara