> At 20:57 08/01/2004, George Schlossnagle wrote: > > >On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote: > >> > >>Personally, I'm not convinced this is that case, even if the people we're > >>dealing with run thousands of Apache processes per server (which they do). > > > >Unless they're running thousands of apache server instances (not just > >children), shouldn't the memory sit in shared pages and thus be completely > >insignificant? > > > >And if they are running 1000s of instances per server, perhaps they have > >an architectural problem that this band-aid won't fix? :) > > Obviously we're talking about httpd children and not 1,000 > roots... Anyway, depending on the module, if there's any sort of RINIT > initialization, the CoW trick doesn't work very well and it consumes some > per-process memory. There's also the function table which is not shared > and will grow by a few dozen kilobytes thanks to the extra functions, which > is not shared across children. > > Note, my position at this point is that there's probably very little gain > in this as well, unless we can find a large number of modules with a > significant amount of functions, some of them maybe doing their own > per-request initialization, thus conserving a significant amount of > per-process memory. The list that Andi posted does not convince me that > this is the case. >
Yep. It also seems silly to reduce functionality based on the memory footprint of a few functions. I sorta agree with the RINIT argument (*), but if its just a function entry - there are many other ways to reduce PHP's memory usage before we get into removing builtin functions. -Sterling (*) I don't think it even has something to do with removing functions, looking at RINIT(basic) there are quite a few places that can be optimized without removing builtins. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
