[RFC] Drop support for generating preloading script

[nicolas-grekas]

With PHP 8.1, preloading is expected to be of less relevancy so we're wondering about its usefulness.

Dropping support for it in Symfony would mainly mean to stop generating the var/cache/prod/App_KernelProdContainer.preload.php file, which could remove some complexity in the DI component.

I've run a very simple benchmark on a minimal "Hello World" and I do see a performance improvement when enabling preloading.

This is with the php -S dev-server:
php8.2 -S localhost:8080 -t public/ 2>/dev/null -dopcache.preload=/app/config/preload.php

And with composer i -a of course (optimized class-loader).

Here is the blackfire.io comparison:
https://blackfire.io/profiles/compare/5a25b32c-5027-4247-b9b3-721b3c456018/graph

So it looks like yes, not calling the autoloader does yield some perf boost.
While we might not recommand using preloading without care, it does have a use case apparently.

I'm opening this RFC to gather feedback on the topic and to keep some record of the decision about preloading.

What's your experience with it?

[noahlvb]

I would be sad to see this feature go. I use it on a few project where is gives an interesting performance benefit. On php 8.0 it was around 11% less cpu time over an hour. And with php 8.1 the benefit was smaller bit still 9%. So it seems like it became less relevant but I would not say not relevant.

I don't now the inner workings of the DI component, but if the burden of maintenance on this feature is so high maybe it is interesting to extract it into a (community driven) bundle if possible?

[wouterj]

@greg0ire also did tests on a production app with preload on and off if I remember correctly. Maybe you want to join the discussion? 🙂

[greg0ire]

Even did a presentation on this: https://www.slideshare.net/greg0ire/preloading-a-postscriptumpdf?from_search=2

TL;DR: with PHP 8.1, it's probably not worth the triple hassle:

• hassle for the SRE team so that they expose the correct knobs to the dev team (there are traps);
• hassle for the framework, which is the point of this issue;
• hassle for the user because they have to do some find tuning.

I can't say however that I did reasonably good benchmarks on this: I don't have a big monolith on which to test this, and I don't know if I can really trust the figures I saw back then. So while I'm interested in knowing more about this, in the end I have no opinion because I didn't conduct proper tests.

[94noni]

some discussion also happened here symfony/symfony-docs#17643

[nicolas-grekas]

with php 8.1 the benefit was smaller bit still 9%

This matches my bench above. So we should keep supporting preloading then.

[fabpot]

10% is significant. Let’s close.

[ostrolucky]

I have a bizarre case on PHP 8.2 where enabling preloading significantly harmed the performance

can be read as: before enabling preloading -> after enabling preloading -> after disabling preloading to verify -> after re-enabling preloading with tuned opcache settings to verify. All that's changed in between is opcache.preload + opcache.preload_user. I have verified via opcache_get_status that opcache memory and buffers are not full.

I'm not sure where to comment on that so I commented here, because in my case having option to not even generate the preloading script could be useful, as obviously I can't enable preloading with such perf. hit, so PhpDumper is generating it completely unnecessarily.

[hockdudu]

@ostrolucky Are you using a vendor library with many classes by any chance?

In an unrelated case with Psalm performance, we noticed that the analysis became much slower after we installed https://github.com/microsoftgraph/msgraph-sdk-php/. After further inspection, we found out this package uses autogenerated classes from the Microsoft API documentation and thus has many, many classes, about 35k.

If you have preload enabled and also use such a library, I believe this could impact the performance.