On Jan 8, 2004, at 4:24 PM, Sterling Hughes wrote:
p.s. Is there a technical reason the function table could be shareable
across children? I can't think of one of the top of my head.
I guess you're missing a 'not' in this question? :) Anyway, the reason it
cannot be shared is that it also contains user-defined functions. It
starts up as shared (the builtin functions are loaded in MINIT, before the
fork), but very quickly this hash table becomes local to the process
because it's updated with user defined functions.
Right - but then only the hash isn't shared, the allocated functions still
are. I can't believe that the hash array is 100k of memory.
It brings up an interesting point though. If these tables could be separated, having a separate user and builtin function table, then you could save memory on builtin functions, and more importantly, you could further make the symbol table implementation quite a bit lighter. As well as eliminating the hash lookup for builtin functions.
I think this idea (using two hash tables) was rejected during the namespace discussions around here:
http://www.zend.com/lists/engine2/200304/msg00190.html
The purpose is different, but the idea very similar, and the double-lookup problem the same. I don't see the real problem though - the function table is what 32 bytes * numBuckets + some other stuff? numBuckets needs to be pretty big for that to amount to anything.
The compile-time pointer resolution is a nice optimization of course, without without double tables.
George
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
