Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107740
MIME-Version: 1.0
References: <DC8C0F88-1B43-4601-A3D1-2EEA812B89B9@newclarity.net>
 <9d3f9895-5ab6-1d75-4eb2-0ba93f13a8fe@gmail.com> <393e5c3c-9902-f6ed-bbb1-5ba48294168c@xs4all.nl>
 <73f639fa-0161-3ac2-ff7a-c249c83a2596@gmail.com>
In-Reply-To: <73f639fa-0161-3ac2-ff7a-c249c83a2596@gmail.com>
Date: Wed, 30 Oct 2019 22:46:49 +0100
Message-ID: <CAH0Uv3E=N4F6UiqFGuB=2S=7pu=8Uw=yndJY_Rpc+e_wYe3bfQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Optional pre-compiler for PHP8?
From: andreas@dqxtech.net (Andreas Hennings)

On Wed, 30 Oct 2019 at 22:06, Rowan Tommins <rowan.collins@gmail.com> wrote=
:
>
> Hi Dik,
>
> On 29/10/2019 21:44, Dik Takken wrote:
> > Opcache already performs type inference. [...]
> > Here is an interesting read on the subject:
> >
> > https://depositonce.tu-berlin.de/bitstream/11303/7919/3/popov_etal_2017=
.pdf
>
>
> Thanks for the link, and the insight into how much OpCache can already do=
.
>
> I guess preloading gets us pretty close to the tool I was imagining -
> OpCache could make assumptions that cross file boundaries, within the
> preloaded set, and could spend longer optimizing during the preloading
> phase than might be expected on a simple cache miss.
>
> I think it will be interesting to see how tools adopt that feature, and
> whether eventually we'll see autoloader functions as just a fallback
> mechanism, with most packages being enumerated in advance as large
> preloaded blocks.

What if we had a "native" autoload layer?
The native autoloader could be made to fire before userland autoloaders.
It could be based on a mapping like PSR-4, or simply a classmap.
The mappings could be defined at "compile time", or frozen early in a reque=
st.

This would allow to predict where each class is located at "compile
time" or at opcache time, allowing to do all the type checks.

An alternative would be to allow userland autoloaders to be registered
with a hash, with the promise that as long as the hash is the same,
classes remain where they are.
Or allow userland to specify "class locators" instead of autoloaders,
which could also be registered with a prediction hash.

So, the overarching idea here is to make autoloading predictable at
compile time or opcache time, and would not require an artificial
"package" concept.

As in my previous proposal, the opcache would have to store different
versions of each file, for different combinations of autoload
prediction hashes.
This would allow e.g. different applications to share some of their
PHP files without spoiling the opcache.

-- Andreas

>
> Regards,
>
> --
> Rowan Tommins (n=C3=A9 Collins)
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>