Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80221
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <006501d02968$3cd39060$b67ab120$@tekwire.net>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
	<CAESVnVqAHJujo0anMi7QYhSZeErcfRVAJ=M7oQMG-huk-bxpCg@mail.gmail.com>
	<006501d02968$3cd39060$b67ab120$@tekwire.net>
Date: Mon, 5 Jan 2015 22:48:40 -0800
Message-ID: <CAEZPtU56cU6DEQe+bP=H6bLkcJOrJnm+U4W_uvFgpe2sXVGW+g@mail.gmail.com>
To: francois@tekwire.net
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Mon, Jan 5, 2015 at 8:21 PM, Fran=C3=A7ois Laupretre <francois@tekwire.n=
et> wrote:
>> -----Message d'origine-----
>> De : php@golemon.com [mailto:php@golemon.com] De la part de Sara Golemon
>>
>> So, I've been meaning to propose something *like* this, but with a few
>> key implementation detail differences:
>>
>> 1) Create the notion of "Persistent User Functions/Classes/Constants/etc
>>
>> 2) Embedded text sections
>
> First, persistent PHP code or data (NOT reloading code for each request) =
is a huge can of worms. If Sara decides to re-launch the idea, that will be=
 great but the subject is probably out of scope here.
>
> IMHO, what we need here is a generic mechanism to embed PHP code in C ext=
ensions and, then, execute it. It should define a way to embed PHP scripts =
as C strings at compile time, how to make these scripts known and accessibl=
e from the PHP core, and how to execute them when needed.
>
> Instead of including the runtime code in every extensions, as it is done =
in ext-embed, I would prefer an extension which would provide this service =
to other 'client' extensions. It would define a stream wrapper to access th=
e registered PHP scripts. Script registration would be registered in persis=
tent memory during MINIT. The registration would return an ID for each regi=
stered script. These IDs would be stored by the client extension and would =
be used to derive a stream-wrapped path when the client decides to execute =
a registered script. These paths would uniquely reference the scripts, whic=
h would allow to opcode-cache them.
>
> As a specific case, if an extension wants to execute some PHP code at the=
 beginning of each request, it can execute its script(s) during RINIT, but =
it is just a use case of a more general mechanism. RINIT execution order ca=
n be resolved using module dependencies.
>
> Extending the mechanism to userspace 'plain file' scripts could be provid=
ed by a 'bridge'. The user could register a plain file script, whose conten=
t would be stored in persistent memory, with a flag that would cause the sc=
ript to be loaded during every RINIT.
>
> One more word about executing scripts during every RINIT : even with opco=
de caches, as Sara notes, the performance hit is not negligible. The questi=
on is always the same : What is the percentage of requests that will really=
 use the classes/functions we define there ? Remember that the list of scri=
pts is hardcoded in an extension. If the extension wants to allow condition=
al loading for different features, it needs to define appropriate ini setti=
ngs. Choosing the list of scripts at compile time is another option but wou=
ld make the distribution of precompiled binaries complex.
>
> I personally favor another approach. I still use the PHK extension as an =
example of this 'intermediate' approach. This extension defines C-levels fr=
ont-end classes. These classes contain the 'fast' code. When this code need=
s to access 'slow' PHP code, it executes the PHP scripts it needs, then cal=
ls the just-defined PHP classes.  This way, we preserve the possibility to =
code a big part of the extension in PHP, without the overhead of loading th=
e PHP code at the beginning of each request.
>
> Thanks for your attention :)

It looks to me that it is going slightly too far, or I totally miss
why it is such a critical feature.

As a developer of (too) many extensions, I can only agree with other
developers saying that many times, writing some glue code in PHP is
way easier than doing it in C using the PHP internals APIs. This is a
one of the biggest problem PHP internals have. Sara and many other
pointed out this problem numerous times in the past. PHP 7 is an
unique opportunity to provide easier APIs to develop extensions even
if we keep the existing ones for obvious reasons.

For example HHVM provides a neat one, which is simply PHP for simple
cases. Complex cases allow advanced the native support is also
supported. See https://github.com/facebook/hhvm/wiki/Extension-API.

Zephir (https://github.com/phalcon/zephir) provides also a clean
solution and easier to maintain or implement PHP extensions.

Python or Perl also provides much cleaner APIs and mix of C and
scripts for extensions developers.

To me, it looks like this is what we should try to solve instead of
creating something we will most likely regret very soon. Benjamin's
original proposal (if technically possible in such a simple way, but I
am not sure about that :) ) is somehow more acceptable than Sara's one
(statically built scrpts with the extension. For one, statically build
scripts into extensions looks to me like statically linking libc. It
also kills any of the advantages of having a glue code, from a release
point of view.

The last thing I do not understand, from Benjamin's point of view, is
the performance part. PHP glue code is used for areas where
performance is not a matter, but then we may end adding this
featurebecause the performance impact is too big. What do I miss? If
the prepend or script loading process are too slow, we should try to
fix this bottleneck instead of opening yet another can of worms.
However I do not see this part of a request as the bottlenecks for
most PHP apps (with opcache).

I do not try to be negative or aggressively opposed to this feature. I
simply think we are trying to solve the wrong parts of the problems.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org