Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125145
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 23 Aug 2024 09:13:19 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <98675de0-cc1e-465f-8cde-507e03371ce3@app.fastmail.com>
In-Reply-To: 
 <CADU7aosqinbQODpoqGADFhr6cx=1HEsdG+9O=JbiKs15qAjcRA@mail.gmail.com>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
 <CADU7aosqinbQODpoqGADFhr6cx=1HEsdG+9O=JbiKs15qAjcRA@mail.gmail.com>
Subject: Re: [PHP-DEV] State of Generics and Collections
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Aug 23, 2024, at 4:58 AM, K=C3=A9vin Dunglas wrote:
> Thanks for sharing this research work.
>
> Instead of having to choose between fully reified generics and erased=20
> type declarations, couldn't we have both? A new option in php.ini coul=
d=20
> allow to enable the =E2=80=9Cerased=E2=80=9D mode as a performance, pr=
oduction-oriented=20
> optimization.
> In development, and on projects where performance isn't critical, type=
s=20
> (including generics) will be enforced at runtime, but users will have=20
> the option of opting to disable these checks for production=20
> environments.

Strictly speaking, yes, a disabled-types mode could be made regardless o=
f what happens with generics.  But the downsides of that approach remain=
 the same.  I'm personally against type erasure generally, in large part=
 because I don't know what it would break in terms of reflection, and in=
 part because I *know* people will turn it off for dev, too, and then en=
d up writing buggier code.

> If this is not possible, the inline caches presented in the article,=20
> combined with =E2=80=9Cworker=E2=80=9D runtimes such as FrankenPHP, Sw=
oole, RoadRunner,=20
> etc., could make the cost of enforcing generics negligible:=20
> technically, types will be computed once and reused for many HTTP=20
> requests (because they are handled by the same long-running PHP script=20
> under the hood). As working runtimes already provide a significant=20
> performance improvement over FPM, we could say that even if=20
> non-performance-critical applications (most applications) will be a bi=
t=20
> slower because of the new checks,  people working on=20
> performance-sensitive applications will have the opportunity to reduce=20
> the cost of checks to virtually nothing by switching to a=20
> performance-oriented runtime.

From talking to Arnaud, the main issue here is the file-at-a-time compil=
ation.  I'm not entirely clear if a persistent process would side-step t=
hat, with the delayed resolution bits, or if those would have to be re-r=
esolved each time.  (That's an Arnaud question.)  Another possibility th=
at's been floated a bit, tangentially, is allowing some kind of multi-fi=
le loading, which would allow for a larger scope to be included at once =
as an opcache segment, and thus the optimizer could do more.

That said, I suspect the benefits of the JIT when using a worker-mode ru=
nner would be larger anyway.

Also, speaking for me personally and no one else, I am still very much i=
n favor of official steps to improve worker-mode options in php-src dire=
ctly.  What form that takes I'm not sure, but I would very much favor ma=
king worker-mode a first-class citizen, or at least a one-and-a-half cla=
ss citizen, rather than its current second-class status.

--Larry Garfield