Re: Garbage collector patch

I could be wrong, of course, but my guess is that the ~3% speed decrease a) is not really significant to 95% of the users (I mean _really_ significant; of course, everyone is going to whine about it first) and b) is going to be eliminated over time david Am 04.12.2007 um 03:43 schrieb 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 --PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

-- David Zülke dz@bitxtender.com Tel: +49 (0)89 57 08 15 15 bitXtender GbR Paul-Heyse-Straße 6 80336 München