Re: PHP 4.0 Bug #8889: Memory is not being freed.

OK, I'll try to summarize. > Because it will hurt performance, and gaining performance usually costs > much more that gaining memory (compare expense for doubling memory and > doubling performance). Most people in most cases are willing to trade > memory for performance - that's why caching exists. 1. I agree, but I agree also with Brian (see http://marc.theaimsgroup.com/?l=php-dev&m=98081424122248&w=2 ). 2. From our tests we cannot say, that CPU performance is considerably better when cache is enabled (on RH6.2 it is less than 10%). I've already written about it. When there are x servers to upgrade with extra RAM memory - this COSTS (especially in Poland ;). 3. "We are free to turn it off" - Yes, but now there are no simply means to do that. So "we demand" some option in .configure script, of course cache should be on by default. Now we can use solution described in http://marc.theaimsgroup.com/?l=php-dev&m=98053283403331&w=2 It has been tested much, but no warranty ! 4. >And, BTW, you can control it - see MAX_ constants at zend_alloc.h As I CLEARLY (as I think ...) described in http://marc.theaimsgroup.com/?l=php-dev&m=98080647502573&w=2 the mechanism of memory "deadlocks" is not based on the cache size (it is small in fact), but in order of memory operations (problem appears even when the size is set to 1 !). We've tested some very simple fixes (turn off ZEND_FAST_CACHE and for example force the shutdown_memory_manager always to clean the cache, not only when "clean" flag is set. It needs some small modification in for loop in order to reinitialize cache globals) and the problem has dissapeared (almost, but I'll say about it later in 5). The CPU performance lowers down only a little bit. 5. We've found out that not only the php memory caches are responsible for described effect. When we use oci8 module - the effect comes back (but in smaller size), because there's independent memory management in that module (and in oracle libraries). We are working on it. I hope this discussion shall result in most effective and flexible solutions. Filip Sielimowicz sielim@wp-sa.pl