On Wed, 30 Oct 2019 at 22:06, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > Hi Dik, > > On 29/10/2019 21:44, Dik Takken wrote: > > Opcache already performs type inference. [...] > > Here is an interesting read on the subject: > > > > https://depositonce.tu-berlin.de/bitstream/11303/7919/3/popov_etal_2017.pdf > > > Thanks for the link, and the insight into how much OpCache can already do. > > I guess preloading gets us pretty close to the tool I was imagining - > OpCache could make assumptions that cross file boundaries, within the > preloaded set, and could spend longer optimizing during the preloading > phase than might be expected on a simple cache miss. > > I think it will be interesting to see how tools adopt that feature, and > whether eventually we'll see autoloader functions as just a fallback > mechanism, with most packages being enumerated in advance as large > preloaded blocks.
What if we had a "native" autoload layer? The native autoloader could be made to fire before userland autoloaders. It could be based on a mapping like PSR-4, or simply a classmap. The mappings could be defined at "compile time", or frozen early in a request. This would allow to predict where each class is located at "compile time" or at opcache time, allowing to do all the type checks. An alternative would be to allow userland autoloaders to be registered with a hash, with the promise that as long as the hash is the same, classes remain where they are. Or allow userland to specify "class locators" instead of autoloaders, which could also be registered with a prediction hash. So, the overarching idea here is to make autoloading predictable at compile time or opcache time, and would not require an artificial "package" concept. As in my previous proposal, the opcache would have to store different versions of each file, for different combinations of autoload prediction hashes. This would allow e.g. different applications to share some of their PHP files without spoiling the opcache. -- Andreas > > Regards, > > -- > Rowan Tommins (né Collins) > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
