I don’t read php-internals anymore because I’m partial to getting work done, but there was an interesting question the dealmac developer posted. Basically dealmac, like my current employer, has a large array structure in a PHP file somewhere that is included on every page. It’s abusing memory.
Brian then notices that if you use var_export()(a function I keep forgetting exists), he was able to cut the memory usage from 5MB to 1.2MB. Storing it serialized reduced the memory usage to 20% but with double to load time performance penalty.
How could a 300K file use up so much space in memory?
The way you answer this is to use vld to make the Zend Engine your bitch.
[The answer after the jump.]
What VLD is
Vulcan Logic Disassembler was written by Derick and Andrei back in the dark ages of PHP 4 when opcode encryption was in vogue. Nobody remembers it exists which is a pity because it’d make things like PINT a whole lot easier to swallow (pardon the pun).
It’s a PHP extension that does something real simple: it spits out the Zend opcodes of a script.
A simple explanation of the way PHP runs is that your PHP scripts are parsed by into symbols, and those symbols are turned into a set of virtual assembly language instructions called opcodes that are stored in oparrays that are indexed by the filename (or function name etc.).
Then Zend Engine is a virtual machine that executes the opcodes in the main oparray. If it hits certain events like an include() or eval(), then it starts up the PHP engine to repeat the process and add to the oparrays.
All of those oparrays are stored in memory during execution, and are sometimes cached by code caching mechanisms like Zend Platform, APC, XCache, what-have-you.
If you understand this than you can answer two interview questions I always ask candidates (and they always bomb).
12 lines later…
So I pasted the code sample Brian gave a segment into a file called “big_array_array.php.”
I then wrote a script called “big_array_make.php” to make the other two files I needed.
Now run vld on the stuff (remember to mod your php.ini file to load vld)
test$ php -dvld.active=1 big_array_array.php 2>output1.txt test$ php -dvld.active=1
Here is a relevant sample of array segment that writes two elements
filename: /home/tychay/compile/utils/big_array_array.php function name: (null) number of ops: 202 line # op fetch ext operands ------------------------------------------------------------------------------- 3 0 FETCH_W $0, 'CATEGORIES' 1 FETCH_DIM_W $1, $0, 202 2 FETCH_DIM_W $2, $1, 'id' 3 ASSIGN $2, '202' 4 4 FETCH_W $4, 'CATEGORIES' 5 FETCH_DIM_W $5, $4, 202 6 FETCH_DIM_W $6, $5, 'name' 7 ASSIGN $6, 'clothing+%26+accessories'
4 opcodes to write each element, 3 registers created per element…
Here is a relevant sample of a var_export() segment that writes the same two elements
filename: /home/tychay/compile/utils/big_array_varexport.php function name: (null) number of ops: 80 line # op fetch ext operands ------------------------------------------------------------------------------- 4 0 INIT_ARRAY ~1, '202', 'id' 5 1 ADD_ARRAY_ELEMENT ~1, 'clothing+%26+accessories', 'name'
1 opcode per array element, 1 register for entire thing, <1 reference/element.
Here is the entire oparray for the serialize version:
5 opcodes, 2 registers for the entire structure.
I wonder if ZendPlatform optimizes the first case. Does anyone know if the output of VLD is valid if ZendOptimizer is on?
I like to thank Brian for pointing out var_export(). It’s surprisingly efficient than I thought and possibly a nice alternative to serialize for special cases (no references, no objects). I’ll have to use the new Benchmark2 I wrote (but haven’t had time to blog) to decide.
9 thoughts on “The Zend Engine is my bitch”
VLD on the actual categories array yields.
code (334k file)
2.7MB disassembled output file
export (244k file)
2,083 temporary registers
830K disassembled output file
ser (220K file)
360K disassembled output file
(Obviously not all instructions run at the same speed. The registration space should be freed at the end of the execution if the oparray, but the oparray itself will stay resident in memory for the entire execution.)
VLD should work with the optimizer on, however, it changes some opcodes so that it’s not always 100% correct (as opcode types are added for example).
I think I’ve already talked about this a while back on my blog (not that anybody reads it)
except, instead of using var_export, I was trying hack array merges into APC’s optimizer
in the whole, learning what all is broken in the optimizer … eventually throwing out the entire optimizer in the process 🙂
Thanks. I read your blog, or at least references to your blog. For instance, just the other day I was considering whether your now #define’s-for-real extension could be used on our site. 😛
As for the vlc thing. There is actually a nice little tutorial on building your own VLD in George’s Advanced PHP Programming book. “Not that anyone reads it.”
VLD worked well before zendOptimizer version 3.0 but after 3.0 optimzer does not work if vld is installed.
So, the point is that you were filling an array inefficiently. Someone might learn PHP, others might look at the var_export() output… but why the hell would anyone use VLD for such a purpose?! Funny.
VLD shows you how the PHP compiler tells the virtual machine to execute a set of commands. “Learning PHP” won’t tell you the answer, and the answer itself will vary from PHP version to version. For all I know, since the article was written, the compiler has changed to be more efficient for assignments and serialize may benchmark much faster.
We can say through Zend fastest execution. We can encrypt our code for security point of view. Server fast response and execution of script fast and optimize