> At 23:24 08/01/2004, 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. > > 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). >
yep.. forgot about that. > 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 :) I was agreeing with you. :) > > >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... > the reason that a symbol table needs to be a hasharray as opposed to a simple hashtable is the distinction between builtin functions and user functions as a reverse_apply() is required at request shutdown. if you separate the tables, you no longer need to reverse apply over the symbol table. > >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. > that's what i thought too, but i remember that thies and i had a problem with apc and builtins + vtable caching (storing it in the ops). Would be even better if I was proved wrong, of course. > >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 :) yeah. i wasn't saying tommorow, but i am saying it should be done before we rip out internal functions for memory size. :) -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
