Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89214
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
To: Stephen Coakley <me@stephencoakley.com>, internals@lists.php.net
References: <12.A1.62946.CB756465@pb1.pair.com>
Message-ID: <56474220.8040603@php.net>
Date: Sat, 14 Nov 2015 15:16:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <12.A1.62946.CB756465@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Support for writing and executing compiled opcode
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

Hi Stephen,

Le 13/11/2015 22:35, Stephen Coakley a écrit :
> Hello all,
>
> 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.
>
> 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).
>
> 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.
>
> Another option would be to add a command-line flag to the interpreter 
> to write compiled opcode instead of executing it after parsing.
>
> Another part of the feature would be to enable the interpreter to 
> execute compiled opcode scripts directly. This would work for both 
> compiled scripts passed to the interpreter, and scripts loaded with 
> `include` and `require`. We would probably need to introduce a new 
> file extension to specify opcode files. I'd recommend *.phpo or *.phpc.
>
> This is quite similar to Python's ability to execute Python scripts 
> compiled to bytecode as *.pyc files. The feature has seen great 
> success in Python, mostly for distributing releases of software or 
> deploying to a server.
>
> I'm not at this moment planning an RFC, but I'd like to gauge your 
> opinions and reactions first.
>

AFAIK, generated bytecodes are not compatible across PHP versions. It 
may work for relatively similar versions and preferably in acscending 
order (executor more recent than compiler) but nothing is guaranteed. 
So, in practice, you cannot distribute pre-compiled code if you must 
impose a specific PHP version to execute it.

Python chose to maintain a backwards compatibility between compiler and 
executor. PHP chose to cache transient opcodes. It may seem weaker but, 
IMO, this is a better approach because it allows a total freedom when 
creating, deprecating, and managing opcodes. Working on the engine would 
be much harder if we had to maintain BC on pre-compiled code.

In practice, distributing pre-compiled PHP scripts wouldn't have any 
noticeable impact on performance because anyone whi cares about 
performance will enable opcache first (which should even be enabled by 
default, IMO). As Sara noticed, the only benefit would be obfuscation, 
which probably deserves a more powerful and reliable mechanism.

Regards

François