preloading is also mostly dead since 8.1

@nicolas-grekas what do you mean with this sentence ?

I mean that preloading might not be worth the trouble it is to maintain and setup anymore...

I think the current state of the implementation won't work: shouldn't a class that depends on a non-preloadable class also be flagged as non-preloadable?

Indeed, I missed 3 points:

1. The Preloader browse the classes, properties and methods parameters to discover more classes.

This is now fixed by doing the ~same thing in PHPDumper.

2. The preloader usesget_declared_classes to browse more classes

This one is tricky because, in PhpDumper, I can't easily do the same for each discovered class. That would require a tokenizer, or callingget_declared_classes in an isolated process => big overhead.

I fixed it by pre-filling the$preloaded parameter of the Preloader to prevent it to browse the classes I known to be not pre-loadable.

3. The generated.preload file is full ofrequire_once included in the Dumped Container

I have no choice but removing the container from the.preload.php file. (in my case, the code preloaded 2300 files before, and 1900 after that change)

This one is quite important as currently, Symfony 6.0 is broken when using pre-loading.

See#44494 for an alternative

Closing in favor of#44494

reopening: Removing typehinted property insymfony/symfony: 6.0 is a workaround for our internal classes, but the bug still exists for other dependencies.

The current implementation of the preloads script discovers all classes used by the end-user. Every third-party package/bundle with type hinted property will hit the same bug.

Worst case, this PR should be merged in 6.1 and type-hint re-added.

This one should be rebased on 6.1 then.

The preloader uses get_declared_classes to browse more classes

This one is tricky because, in PhpDumper, I can't easily do the same for each discovered class. That would require a tokenizer, or calling get_declared_classes in an isolated process => big overhead.

Could we fix this by registering an autoloader that only collects autoloaded symbols before the real autoloader?

The generated .preload file is full of require_once included in the Dumped Container

I have no choice but removing the container from the .preload.php file. (in my case, the code preloaded 2300 files before, and 1900 after that change)

You mean in the initializer that is called on the first call toset() since#44010, right?
We might be able to fix this by not callingset() but listing the files/classes in the preload script instead, isn't it?

What about another alternative: deprecate generating the preload script at all?

Since 8.1, preloadingprovides almost no benefits to me.

Preloading is (was?) also sensitive to "over-preloading" (aka preloading too many classes, making it under-perform due to hash table overhead), so that any benefits provided by preloading might easily be canceled by having it not properly configured. And since configuring it is quite difficult, the gain might not be reachable in practice.

Also, I guess 8.1 is able to cache the same class/symbol for different paths, while preloading cannot.

I'd be interested in knowing@nikic's thoughts on the topic!

Or we could make the preloading script extremely simpler, eg preloading only composer+some very basic stuffs.

BTW, would it possible to turn that fatal error into a warning on PHP 8.0, as a bugfix?

BTW, would it possible to turn that fatal error into a warning on PHP 8.0, as a bugfix?

Nope, the fatal error is required for correctness in 8.0.

As to preloading in general, the usefulness is greatly diminished with 8.1, but I don't really have data on whether there are any cases where it still makes sense.

As we've added the type to properties again in the 6.1-dev branch, what is needed to finish this PR? Is there anything I (or the community) can do to help move this forward?

Replaced by#45377

Thank you very much for providing this patch@jderusse, it's been critical to make an informed decision on the topic! 🙏