On 28-10-19 00:04, Rowan Tommins wrote: > - a static analyser that can infer types in a PHP program; we know > that's possible from a number of third-party tools, although they do > rely on docblock comments for things the language doesn't (yet) let you > define
Opcache already performs type inference. It does not make use of information in comments. It only looks at the code, yielding type information that is accurate and can be used for optimization. Here is an interesting read on the subject: https://depositonce.tu-berlin.de/bitstream/11303/7919/3/popov_etal_2017.pdf > The first problem is that OpCache is designed to work one file at a > time, because a program can load any combination of files at run-time. > Static analysers, on the other hand, need to process a whole directory > at a time, so that calls can be matched to definitions; multiple > definitions of the same function or class tend to cause problems, even > though only one is loaded at run-time. So we'd probably need some > built-in definition of a "package", which could be analysed and compiled > as one unit, and didn't rely on any run-time loading. This problem could possibly be solved by using preloading. The definition of a package would then be: the set of files that the application will load during startup. Preloading could give opcache access to the full application and optimize more effectively. > The second problem is that, as I understand it, type checks aren't > actually separate OpCodes, so eliminating them from the compiled program > may not be that easy. There are some cases where you can just eliminate > the type check from a definition, e.g.: This is partially correct. Some type checks are separate opcodes, some are not. Type checking opcodes are actually removed by opcache when its static analysis can prove that the type check will always pass. It has some limitations but the functionality is all there. Regards, Dik Takken -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
