Re: Ability to lower PHP memory usage
| From: | Marcus Boerger | Date: | Thu, 08 Jan 2004 17:27:14 +0000 |
| Subject: | Re: Ability to lower PHP memory usage | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-6860@lists.php.net to get a copy of this message | ||
Hello Andi,
Thursday, January 8, 2004, 6:02:42 PM, you wrote:
> At 02:24 PM 1/8/2004 +0100, Christian Schneider wrote:
>>Stanislav Malyshev wrote:
>>>I'm concerned that this problem of breaking common platform might be more
>>>dangerous than the performance benefit. Which, BTW, I estmate as pretty
>>>minimal - code space is shared on all modern OSes anyway, so a little
>>
>>I think that's a good point for leaving it the way it is: Minimal benefit
>>while opening a can of worms of possible problems.
>>
>>Another reason not to do it is the amount of work to decide which function
>>should go where. Let's keep it simple and focus on IMHO more pressing problems.
> Guys,
> You are all missing the point. All the ext/standard would still be enabled
> by default,
Seems like everyone sees builtin/enabling by default as a minimum
requirement for such an approach.
> but it would allow people with very high traffic sites who need
> to save every bit of memory they can to build a lean-and-mean version of PHP.
> These kinds of users are looking for optimizing PHP for their application
> and do it with a sane mind.
In highspeed scenarios you wouldn't use CGI but a module. There the memory
consumption by php core doesn't change after the worker threads/processes
are started. The benefit here would be reduced function tables and hence
faster function lookup. But if i would deal with such a site i would first
disable some function calling overhead in the engine. That should bring much
more. Maybe we should add some #ifdef's there combined with a (--very-fast)
option that on the other hand would disable features like the tick operator.
--
Best regards,
Marcus mailto:helly@php.net