Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108108
MIME-Version: 1.0
References: <CAMuFt-6=FaqRpTEvZDtW_OsLmq3R171nDc7wH0D5itJUosMtdQ@mail.gmail.com>
 <d2348c4b-7993-489e-86ed-01932a864ec9@www.fastmail.com> <CD056374-BE4F-4B7F-A0F1-5481D024AE8A@newclarity.net>
In-Reply-To: <CD056374-BE4F-4B7F-A0F1-5481D024AE8A@newclarity.net>
Date: Mon, 13 Jan 2020 07:39:05 +0000
Message-ID: <CAMuFt-7ySUKpOGXFd4F5mLReumb+t30-hqvx1AdRdRf9VJG6+Q@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
From: robehickman@gmail.com (Robert Hickman)

I would say that my proposal is more about compile-time meta
programming, and thus would not actually depend on preloading. It
could also be ran during page requests and would be cached by opcache
in the same way. However running it in that way could make the initial
request before the opcodes are cached much slower. Hence why combining
it with preloading would be advantageous.

On Mon, 13 Jan 2020 at 00:45, Mike Schinkel <mike@newclarity.net> wrote:
>
> > On Jan 12, 2020, at 1:57 PM, Larry Garfield <larry@garfieldtech.com> wr=
ote:
> >
> > Most notably, *not all code will be run in a preload context*.
>
> Can you give some concrete examples here?
>
> > Language features that only sometimes work scare me greatly.
>
> Do you have some examples of  language features, from PHP or another lang=
uage, that only work sometimes and that are known to be problematic. and wh=
y they are problematic?
>
> > Doing one-time optimizations in preload that make the code faster, that=
's great.
>
> Though I think this proposal may need to be fine-tuned, I can envision ma=
ny frameworks and CMSes written in PHP could improve both performance,  rob=
ustness and user-experience using preloading.
>
> One of the ways most useful would be to run code that ensures the framewo=
rk/CMS APIs are being used correctly.  If this code is included today in fr=
ameworks and CMSes, it must run for every page load (on the web) when it co=
uld be run once when OpCode is generated. This could potentially improve pe=
rformance significantly, depending on how much checking it implemented.
>
> It could also improve performance of building data-driven structures at r=
untime. I know that in the past I have had data driven structures that were=
 definitely very time-consuming on each page load.  The WordPress admin doe=
s tons of it.
>
> > Preload optimizations that make the code behave differently, that's ext=
remely dangerous.
>
> Can you give some concrete examples where you fear this could happen?
>
> > "I changed one character and now I have to restart my webserver to see =
if it did anything" is a bad place for PHP to be.
>
> As I envision it preloaded code of this nature would not be handled on se=
rver reboot, but when the files have had their time stamps updated. If I am=
 not mistaken, PHP already does this (but I could be mistaken as I don't ha=
ve expertise in PHP OpCodes.)
>
> Whatever the case I think this could easily be handled with a simple API =
call to flush preloaded code which for debugging could be one of the first =
things a developer would call in their codebase.
>
> > I am highly skeptical about allowing arbitrary preload/compile time beh=
avior as it makes development harder and bifurcates the ecosystem.
>
> Given the copious performance and robustness benefits that preloading cou=
ld provide, I would think we should try and identify specific concrete conc=
erns rather than allow unidentified concerns from blocking a potentially gr=
eat improvement to the language.
>
> So what specific concrete concerns can we identify?
>
> > To your specific examples, many are already possible today.  Code gener=
ation in a pre-execute build step is increasingly common; the Symfony ecosy=
stem does a ton of it, I've implemented a compiled version of a PSR-14 Even=
t Dispatcher, etc.
>
> Am I understanding correctly that requires a _build_ process, and not som=
ething that a PHP developer can depend upon having available on any hosted =
PHP server?
>
> > Code generation at that point is then impossible.  Moving that code gen=
 to a preloader wouldn't help with that.
>
> As Robert stated, he is not proposing any code generation.
>
> His preloading concept would modify classes by manipulating the AST, whic=
h, IMO would require an additional API. And I do think it is probably ortho=
gonal to the idea of preloading code although I do think it would also have=
 great benefit too, but that preloading is probably a prerequisite.
>
> > I appreciate the intent here, but in practice I'd much rather we limit =
preload optimization to things the engine can do for us, and reliably know =
that it can do so without changing behavior.
>
> Limiting in that manner would effectively eliminate the possibility of se=
rendipity that can occur when userland developers are empowered vs only tho=
se who can sufficient agreement to add features to PHP. IOW, tiny subset of=
 problems could be solved if we limit vs. the number of problems developers=
 could solve for themselves and offer to the open-source to the community i=
f userland developers are given more control over preloading.
>
> > For example, there's a ton of optimizations that can be done that rely =
on working with pure functions only, but the engine today cannot know if a =
function is pure.  (Or I don't think it's able to figure it out for itself,=
 anyway.)  I'd be fully in favor of ways that we could indicate to the engi=
ne "this is safe to do more computer-science-y optimizations on, do your th=
ing", and then implementing those optimizations in the engine rather than i=
n user space.
>
> There are more innovations that can occur in computer science than just t=
hose that depend on pure functions. Why must we limit ourselves to only con=
sider problems that can be solved with pure functions?
>
> There are a lot of details we would need to work through to have a viable=
 proposal for userland preloading (vs. preloading a sysadmin can control), =
but I assert we'd be better off optimisitically exploring the concept inste=
ad of prematurely stifling exploration.
>
> -Mike