> >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.
They probably aren't, because of the way the hash is and the allocation pattern. First, the bucket and the function container itself probably sit in the same page because they're allocated next to each other. Secondly, the buckets contain list pointers that are updated as the hash is updated. Hence, the functions are also not shared (in other words, the hash buckets actually take many more pages than just their accumulated size).
People, READ, I'm saying that I *DON'T* think that we'd be saving 100K from reducing the size of this hash. Read a couple of more seconds before you say I do :)
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 don't see how it will make the symbol table implementation any lighter...
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.
I don't think they have to be allocated into shm at all in any way. There's really no need for that. You could simply save their pointers as they never change.
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. :)
Interesting thought. Something for 5.1 :)
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
