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:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
