Re: Ability to lower PHP memory usage
| From: | Sterling Hughes | Date: | Thu, 08 Jan 2004 21:24:59 +0000 |
| Subject: | Re: Ability to lower PHP memory usage | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-6914@lists.php.net to get a copy of this message | ||
> >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