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
