On Fri, Aug 23, 2024, at 4:58 AM, Kévin Dunglas wrote:
> Thanks for sharing this research work.
>
> Instead of having to choose between fully reified generics and erased
> type declarations, couldn't we have both? A new option in php.ini could
> allow to enable the “erased” mode as a performance, production-oriented
> optimization.
> In development, and on projects where performance isn't critical, types
> (including generics) will be enforced at runtime, but users will have
> the option of opting to disable these checks for production
> environments.
Strictly speaking, yes, a disabled-types mode could be made regardless of 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 end up
writing buggier code.
> If this is not possible, the inline caches presented in the article,
> combined with “worker” runtimes such as FrankenPHP, Swoole, RoadRunner,
> etc., could make the cost of enforcing generics negligible:
> technically, types will be computed once and reused for many HTTP
> requests (because they are handled by the same long-running PHP script
> under the hood). As working runtimes already provide a significant
> performance improvement over FPM, we could say that even if
> non-performance-critical applications (most applications) will be a bit
> slower because of the new checks, people working on
> performance-sensitive applications will have the opportunity to reduce
> the cost of checks to virtually nothing by switching to a
> performance-oriented runtime.
From talking to Arnaud, the main issue here is the file-at-a-time compilation. I'm not
entirely clear if a persistent process would side-step that, with the delayed resolution bits, or if
those would have to be re-resolved each time. (That's an Arnaud question.) Another
possibility that's been floated a bit, tangentially, is allowing some kind of multi-file
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 runner would be larger anyway.
Also, speaking for me personally and no one else, I am still very much in favor of official steps to
improve worker-mode options in php-src directly. What form that takes I'm not sure, but I
would very much favor making worker-mode a first-class citizen, or at least a one-and-a-half class
citizen, rather than its current second-class status.
--Larry Garfield