> >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. During compile time, builtin functions could be resolved to pointers (avoiding a lookup), whereas user functions would still incur the lookup. This should work fine with compiler cache's as well, so long as they have a mechanism for allocating the builtins into shm. This would decrease performance of dynamic function calls (incuring a two phase lookup), but if you use those functions, you've already lost. Just a thought. :) -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
