Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108107
Message-ID: <CD056374-BE4F-4B7F-A0F1-5481D024AE8A@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_914960AE-6E0A-475C-A61E-79FA8B007142"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 12 Jan 2020 19:45:39 -0500
In-Reply-To: <d2348c4b-7993-489e-86ed-01932a864ec9@www.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <CAMuFt-6=FaqRpTEvZDtW_OsLmq3R171nDc7wH0D5itJUosMtdQ@mail.gmail.com>
 <d2348c4b-7993-489e-86ed-01932a864ec9@www.fastmail.com>
Subject: Re: [PHP-DEV] Introducing compile time code execution to PHP
 preloading
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_914960AE-6E0A-475C-A61E-79FA8B007142
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Jan 12, 2020, at 1:57 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> Most notably, *not all code will be run in a preload context*. =20

Can you give some concrete examples here?

> Language features that only sometimes work scare me greatly. =20

Do you have some examples of  language features, from PHP or another =
language, that only work sometimes and that are known to be problematic. =
and why they are problematic?

> Doing one-time optimizations in preload that make the code faster, =
that's great. =20

Though I think this proposal may need to be fine-tuned, I can envision =
many frameworks and CMSes written in PHP could improve both performance, =
 robustness and user-experience using preloading. =20

One of the ways most useful would be to run code that ensures the =
framework/CMS APIs are being used correctly.  If this code is included =
today in frameworks and CMSes, it must run for every page load (on the =
web) when it could be run once when OpCode is generated. This could =
potentially improve performance significantly, depending on how much =
checking it implemented. =20

It could also improve performance of building data-driven structures at =
runtime. 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 does tons of it.

> Preload optimizations that make the code behave differently, that's =
extremely 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 =
server 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 have expertise in PHP OpCodes.)=20

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 =
behavior as it makes development harder and bifurcates the ecosystem.

Given the copious performance and robustness benefits that preloading =
could provide, I would think we should try and identify specific =
concrete concerns rather than allow unidentified concerns from blocking =
a potentially great improvement to the language.

So what specific concrete concerns can we identify?

> To your specific examples, many are already possible today.  Code =
generation in a pre-execute build step is increasingly common; the =
Symfony ecosystem does a ton of it, I've implemented a compiled version =
of a PSR-14 Event Dispatcher, etc.

Am I understanding correctly that requires a _build_ process, and not =
something 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. =20

His preloading concept would modify classes by manipulating the AST, =
which, IMO would require an additional API. And I do think it is =
probably orthogonal 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. =20

Limiting in that manner would effectively eliminate the possibility of =
serendipity that can occur when userland developers are empowered vs =
only those 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 if 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 engine "this is safe to do more computer-science-y optimizations =
on, do your thing", and then implementing those optimizations in the =
engine rather than in user space.

There are more innovations that can occur in computer science than just =
those that depend on pure functions. Why must we limit ourselves to only =
consider 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 instead of prematurely stifling exploration.

-Mike=

--Apple-Mail=_914960AE-6E0A-475C-A61E-79FA8B007142--