
The opcode is not the handler
The same loop ran 23% faster with int parameters, and only with OPcache on. Operand classes pick a handler when the file compiles; proven types pick a different one.
Subject 01 · 10 posts
The engine: compilation, the Zend VM, memory layout, and the data structures behind the values you pass around.

The same loop ran 23% faster with int parameters, and only with OPcache on. Operand classes pick a handler when the file compiles; proven types pick a different one.

phpdbg showed thirteen instructions and the optimizer showed nine. Both were right. How to read the notation, and which listing is the one that runs.

The same .= statement took 0.269 ms and 218.836 ms in two loops that differ by one assignment. What a zend_string costs, where literals live, and why implode is not the fix.

Plain, backed and virtual property reads compile to one identical FETCH_OBJ_R. What separates them is a function call the opcode does not show, measured at nine times.

One hundred thousand four-field records cost 143.54 bytes each as objects and 397.14 as associative arrays. Where the crossover is, and what one undeclared property costs.

Two hundred thousand objects created and dropped, and zero collections. What puts an object in the root buffer, and why the collector's cost is set by what you keep alive.

Walking an array with foreach ($rows as &$row) wraps every element in a zend_reference. On a million integers that is 32 MB the loop never gives back.

A zval is sixteen bytes, a value union and a type tag. What that tag says decides whether an assignment copies anything, what a reference costs, and which variable pays.

One structure serves as list, dictionary and set. Packed and hashed layouts, what each costs in memory, and when a conversion happens.

A request walks from the SAPI to the Zend VM — lexing, compilation to opcodes, the OPcache lookup that skips both, and execution.