Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33621
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain prohost.org from 64.233.166.181 cause and error)
Cc:  <internals@lists.php.net>
Message-ID: <D37F0F93-EA19-4178-BCEE-91A7C36A7650@prohost.org>
To: Andi Gutmans <andi@zend.com>
In-Reply-To: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Mon, 3 Dec 2007 21:43:28 -0500
References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net>
Subject: Re: [PHP-DEV] Garbage collector patch
From: ilia@prohost.org (Ilia Alshanetsky)

First of all big thanks for Dmitry and David for spending time on this  
project and continuing to improve the original patch. Based on the  
results so far, I think the patch does have a value, but certainly not  
in a general case. Relative simple scripts have little to gain from it  
and only to loose 3-5% of speed depending on a situation and given  
insubstantial memory gains it seems of little use in general case.  
That said, there are complex applications (perhaps unnecessarily  
so ;-) ) that could see some real benefits from this code. My  
suggestion is that we make this feature a compile time flag, that's  
off by default and people who feel that their applications warrant a  
garbage collector can enable it for their install and at the same time  
those who don't (general case) have no penalties of having it in place.


On 3-Dec-07, at 4:01 PM, Andi Gutmans wrote:

> Hi all,
>
>
>
> Was hoping to send this off earlier but I was travelling for the past
> week and had very limited email access.
>
> As promised in the past few weeks we have spent a significant amount  
> of
> time in reviewing the garbage collector work and testing it in our
> performance lab. Dmitry has been exchanging ideas and patches with  
> David
> Wang during this time. Suffice to say that as I've mentioned in the
> past, memory management is an extremely sensitive piece of PHP,  
> which is
> why it was important for us to review this work in great depth before
> committing it to the code base.
>
>
>
> The updated patch still retains the same algorithm as David's original
> implementation however the data structures have been changed in  
> order to
> work faster and use less memory.
>
>
>
> The revised patch has the following advantages:
> - It fixes several crash bugs
>
> - Enhances performance by removing several unnecessary checks
> - The memory overhead was reduced (from 12 to 4 bytes for each
> heap-allocated zval)
> - The speed of "clean" PHP code (code that doesn't create cycles) was
> improved
> - Additional test cases were created
>
> The end result is a more stable and faster GC patch. That said we have
> yet to find real-life applications that create significant cycles  
> which
> would benefit from this patch. In fact as you'll see from the results
> our tests show an increase in maximum memory use and slower execution
> (to be fair they are marginal).
>
>
>
> We have tested both PHP_5_3 without any patches, the original patch  
> and
> the new patch.
>
>
>
> The following table shows execution time (seconds for N requests) and
> slowdown.
>
>
>
> 	PHP_5_3
>
> Original GC patch
>
> Current GC patch
>
> 	
>
>
>
> slowdown
>
>
>
> slowdown
>
> bench
>
> 11,550
>
> 12,310
>
> 6,58%
>
> 12,170
>
> 5,37%
>
> hello
>
> 8,781
>
> 8,852
>
> 0,81%
>
> 8,813
>
> 0,36%
>
> xoops
>
> 128,500
>
> 135,100
>
> 5,14%
>
> 130,200
>
> 1,32%
>
> static
>
> 18,540
>
> 20,840
>
> 12,41%
>
> 18,920
>
> 2,05%
>
> qdig
>
> 29,320
>
> 30,270
>
> 3,24%
>
> 29,610
>
> 0,99%
>
> qdig2
>
> 13,960
>
> 14,100
>
> 1,00%
>
> 14,090
>
> 0,93%
>
> The next table shows memory usage in MB and overhead
>
>
>
> 	PHP_5_3
>
> Original GC patch
>
> Current GC patch
>
> 	
>
>
>
> overhead
>
>
>
> overhead
>
> hello
>
> 13,750
>
> 13,945
>
> 1,42%
>
> 13,765
>
> 0,11%
>
> xoops
>
> 18,036
>
> 18,636
>
> 3,33%
>
> 18,568
>
> 2,95%
>
> static
>
> 15,300
>
> 16,000
>
> 4,58%
>
> 15,308
>
> 0,05%
>
> qdig
>
> 14,820
>
> 15,008
>
> 1,27%
>
> 14,828
>
> 0,05%
>
> qdig2
>
> 14,824
>
> 15,012
>
> 1,27%
>
> 14,838
>
> 0,09%
>
>
>
> To summarize the patch lead to approx. 5% slowdown and 3% memory
> overhead for typical applications (as always, you mileage may vary
> depending on your system's architecture and OS although my guesstimate
> is that you will see even worse results in a 64bit environment). We  
> also
> tested SugarCRM to get another sanity for these results and we got
> similar results.
>
>
>
> I am not quite sure where this leaves us with this patch. On one  
> hand I
> think now the effort has been made it's a good thing to offer it as  
> part
> of PHP. The downside is of course some performance degradation and
> possible instabilities as this patch continues to stabilize (it took
> about two releases for us to stabilize the Zend Memory Manager even
> after in-depth testing due to edge cases in allocation patterns and
> various extensions, etc...).I'd be surprised if our team has found all
> possible bugs.
>
>
>
> Personally I think the decision should be either in or out. Adding  
> this
> as a compile option is not a good idea as it would create binary
> compatibility issues and would be a pain for the community. I think my
> inclination is to commit the patch, not have it #ifdef'ed but always
> compiled but to have the garbage collection itself turned off by  
> default
> (mainly for stability reasons. Note: the increased memory footprint  
> and
> performance loss also exists with the collection itself turned off).  
> We
> can turn it on when we're in dev for snapshots so that we iron out  
> bugs.
> That said, as you can see from the results most people and real-life
> applications will be worse off than today.
>
>
>
> Thanks to David & Dmitry for working hard on this (and everyone else  
> who
> contributed).
>
>
>
> The stage is open for ideas/thoughts/suggestions J
>
>
> Andi
>

Ilia Alshanetsky