Hi!
class C { var $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10; }$m = memory_get_usage(); $a = array(); for ( $i = 0; $i< 10000; $i++ ) { $a[] = new C; } print ((memory_get_usage() - $m) / 10000) . "\n"; ?> 1927 bytes (I'll use 64-bit from now on since it gives the most shocking numbers)
OK, you have object with 10 vars - as we established, vars in array take 100-200 bytes overhead (depending on bits - 64bits is fatter) so it fits the pattern.
Then the object could be stored as a zval[10]. Object member access would be implemented by looking up the member name in the class entry hashtable and then using the resulting index into the zval[10]. When the object is unpacked (say if the user creates or deletes object members at runtime), then the object value becomes a hashtable.
That would mean having 2 object types - "packed" and "unpacked" with all (most of) operations basically duplicated. However, for objects it's easier than for arrays since objects API is more abstract. I'm not sure that would improve situation though - a lot of objects are dynamic and for those it would mean a penalty when the object is unpacked. But this can be tested on the current engine (maybe even without breaking BC!) and if it gives good results it may be an option.
Making oplines use a variable amount of memory (like they do in machine code) would be a great help. For declarations, you could pack structures like zend_class_entry and zend_function_entry on to the end of the opline, and access them by casting the opline to the appropriate opcode-specific type. That would save pointers and also allocator overhead.
zend_class_entry is huge, why would you want to put it into the opline? And what opline needs static zend_class_entry anyway?
At the more extreme end of the spectrum, the compiler could produce a pointerless oparray, like JVM bytecode. Then when a function is executed for the first time, the oparray could be expanded, with pointers added, and the result cached. This would reduce memory usage for code which is
opcodes can be cached (bytecode caches do it) but op_array can't really be cached between requests because it contains dynamic structures. Unlike Java, PHP does full cleanup after each request, which means no preserving dynamic data.
I'm not sure how using pointers in op_array in such manner would help though - you'd still need to store things like function names, for example, and since you need to store it somewhere, you'd also have some pointer to this place. Same goes for a bunch of other op_array's properties - you'd need to store them somewhere and be able to find them, so I don't see how you'd do it without a pointer of some kind involved.
-- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
