I was reading about Preload and very excited about it, however (as I understood by searching more on Google) they both seem to have the same definition in my mind:
Preload: Loading compiled PHP files on server startup and make all the defined classes and functions to be permanently available in the context of future request (as I understand from here)
JIT: Compilation of files at run time rather than prior to execution
Which one affects the performance more? specially on frameworks
The confusion here is between two different meanings of "compiled"; or, really, the same meaning - transforming a high-level program into a set of lower-level instructions - applied twice to the same program.
Since PHP 4, the PHP code that humans write has been automatically compiled to a more abstract language, called "op codes". These act as instructions for a "virtual machine", but are still very high-level: each op code triggers a whole sub-routine in the Zend Engine.
The OpCache extension included with PHP since version 5.5 not only caches these op codes to save time re-compiling, it performs a lot of optimisations by manipulating them. Pre-loading is part of this mechanism: it runs the compilation and optimisation steps, and saves the op codes for reuse by multiple PHP processes.
However, those op codes are still a long way from what the CPU is actually going to run. The virtual machine that executes them is technically an interpreter, working through a list of instructions, and performing multiple steps even for something as simple as $x + $y
.
The basic idea of JIT in PHP 8 is to supplement that interpreter with a second compiler - this time, compiling from op codes down to actual machine instructions. More specifically, a JIT compiler looks at a section of code as it runs (hence "Just In Time"), and generates a set of CPU instructions to implement it.
Now you may be wondering why we don't do this bit as early as possible - Just In Time seems to be the opposite of pre-loading! The advantage is that the JIT compiler can look at how code is actually being used, rather than all the possible ways it might be used. The interpreter looking at the op codes for $x + $y
has to account for the fact that each time the code runs, those variables might be integers, floats, strings, or something where +
needs to throw an error. The JIT compiler can see that the running program often has them both as integers, and compile some fast code for that scenario. When the other scenarios come up, the JIT compiler just hands back to the normal interpreter.