The Execution Life-cycle
PHP is a scripting language, which most people take to mean that it is not compiled. While this is true in the traditional sense in that we are not calling a gcc or javac; instead we are compiling every time the script is requested. In fact, the PHP and Java compilation life cycles are pretty similar, because they both compile to an intermediary instruction set (opcodes, or bytecodes) which are then run in a virtual machine (Zend VM or JVM).
The parsing and compilation phases is slow. When we add an opcache, we short-circuit this process by storing the result of the parsing and compilation phases, leaving just the execution to run dynamically as always. In effect, we are closer to the Java life-cycle now; with the main differences being that we saved to shared memory instead of a file, and can automatically re-compile if changes occur to the script.
Tokens & OpCodes
Once PHP gets ahold of your code, it creates two representations of your code. The first is tokens; this is a way to break down your code into consumable chunks for the engine to compile into it’s second representation, opcodes. The opcodes are the actual instructions for the Zend VM to execute.
The Worst Hello World Ever
Taking a simple code example, a vastly over-engineered hello world example, lets look at both tokens, and opcodes.
<?php
class Greeting {
public function sayHello($to)
{
echo "Hello $to";
}
}
$greeter = new Greeting();
$greeter->sayHello("World");
?>
Tokenizing
The first part of the compilation process parses the code into tokens. These are passed to the compiler to create OpCodes.
|
Token Name |
Value |
|
|
<?php |
|
|
class |
|
|
|
|
|
Greeting |
|
|
|
|
{ |
|
|
|
|
|
|
public |
|
|
|
|
|
function |
|
|
|
|
|
sayHello |
|
( |
|
|
|
$to |
|
) |
|
|
|
|
|
{ |
|
|
|
|
|
|
echo |
|
|
|
|
" |
|
|
|
Hello |
|
|
$to |
|
" |
|
|
; |
|
|
|
|
|
} |
|
|
|
|
|
} |
|
|
|
|
|
|
$greeter |
|
|
|
|
= |
|
|
|
|
|
|
new |
|
|
|
|
|
Greeting |
|
( |
|
|
) |
|
|
; |
|
|
|
|
|
|
$greeter |
|
|
-> |
|
|
sayHello |
|
( |
|
|
|
"World" |
|
) |
|
|
; |
|
|
|
|
|
|
?> |
As you can see, most discrete piece of the code is given a name, starting with T_ and then a descriptive name. This is where the infamous T_PAAMAYIM_NEKUDOTAYIM error comes from: it represents the double colon.
Some tokens do not have a T_ name, this is because they are a single character — it would obviously wasteful to then assign them a much larger name — T_DOUBLE_QUOTE or T_SEMICOLON don’t make much sense.
It is also interesting to see the difference interpolation of variables makes; take the two strings, both double quotes, "Hello $to" and "World", the first, to account for the interpolated variables is split into 4 unique opcodes:
|
" |
|
|
|
Hello |
|
|
$to |
|
" |
and the non-interpolated string is simply one:
|
|
"World" |
With this view we can start to see how small choices we make start to affect performance in miniscule ways (and frankly, especiallyin this case, as with single Vs double quotes, it’s not worth caring about!)
You can see the script that was used to generate this list of tokens here.
OpCodes
Next, lets look at how this looks like once we have compiled to opcodes. This is what the OpCode caches store.
To get the opcodes, we run the script through VLD, the Vulcan Logic Dumper, a pecl extension for PHP. To install it simple run:
$ pecl install vld-beta
And make sure the following is added to your PHP config:
| extension=vld.so |
Once you’ve done this, you can dump the opcodes for any code using the following on the command line:
$ php -dvld.active=1 -dvld.execute=0 <file>
VLD dumps global code (main script), global functions, and then class functions. However we’re going to look at our class functions first so as follow the same flow as the code itself.
Understanding VLD Dumps
A VLD dump is typically multiple dumps, one for the main script, then one for each global function and class function. Each dump is identical in structure.
First is the header which lists (if applicable) the class, and the function; then it lists the filename. Next it lists the function name (again, and only if applicable).
| Class Greeting: | |
| Function sayhello: | |
| filename: ./Greeting.php | |
| function name: sayHello |
Next, it lists the total number of opcodes in the dump:
| number of ops: 8 |
And then it lists the compiled variables (see below for details):
| compiled vars: !0 = $to |
This is particularly important to take notice of.
Finally, it actually lists the opcodes, one per line, under the heading row:
| line # * op fetch ext return operands | |
| ------------------------------------------------------------------------ |
Each opcode has the following:
-
line: The line number in the source file -
#: The opcode number -
*: entry (left aligned) and exit points (right aligned), indicated by greater than symbols (>) -
op: The opcode name -
fetch: Details on global variable fetches (super globals, or the use of the global keyword) -
ext: Extra data associated with the opcode, for example the opcode to which it should JMP -
return: The location where return data from the operation is stored -
operands: the operands used by the opcode (e.g. two variables to concat)
Note: Not all columns are applicable to all opcodes.
Variables
There are multiple types of variables within the Zend Engine. All variables use numeric identifiers.
- Variable prefixed with an exclamation point (!) are compiled variables (
CVs) — these are pointers to userland variables - Variables prefixed with a tilde (~) are temporary variables used for temporary storage (
TMP_VARs) of in-process operations - Variables prefixed with a dollar ($) are another type of temporary variables (
VARs) which are tied to userland variables like CVs and therefore require things like refcounting. - Variables prefixed with a colon (:) are temporary variables used for the storage of the result of lookups in the class hashtable
Dumping Hello World
| Class Greeting: | |
| Function sayhello: | |
| number of ops: 8 | |
| compiled vars: !0 = $to | |
| line # * op fetch ext return operands | |
| ---------------------------------------------------------------------------- | |
| 3 0 > EXT_NOP | |
| 1 RECV !0 | |
| 5 2 EXT_STMT | |
| 3 ADD_STRING ~0 'Hello+' | |
| 4 ADD_VAR ~0 ~0, !0 | |
| 5 ECHO ~0 | |
| 6 6 EXT_STMT | |
| 7 > RETURN null |
Reading this, we see that we’re in the function sayHello of the class Greeting, and that we have one compiled variable, $to, which is identified by !0.
Next, following the list of opcodes (ignoring the no-op), we can see that:
-
RECV: The function receives a value which is assigned to!0(which represents$to) -
ADD_STRING: Next we create a temporary variable identified by a~,~0and assign the static string,'Hello+', where the+represents a space -
ADD_VAR: After this, we concat the contents our variable,!0to our temporary variable,~0 -
ECHO: Then we echo that temporary variable -
RETURN: Finally we return nothing as the function ends
Next, lets look at the main script:
Here we see one compiled variable, $greeter, identified by !0. So lets walk through this, again we’ll ignore the no-op.
-
FETCH_CLASS: First we lookup the class,Greeter; we store this reference in:1 -
NEW: Then we instantiate an instance of the class (:1) and assign it to aVAR,$2, and -
DO_FCALL_BY_NAME: call the constructor -
ASSIGN: Next we assign the resulting object (inVAR $2) to ourCV(!0) -
INIT_METHOD_CALL: We start calling the sayHello method, and -
SEND_VAL: pass in'World'to the method, and -
DO_FCALL_BY_NAME: Actually execute the method -
RETURN: The script ends successfully, with an implicit return of 1.