Andi Gutmans wrote: > That'd be great. > Dmitry, David, can you please send the updated patch to the list?
> Andi
>> -----Original Message----- >> From: Markus Fischer [mailto:mar...@fischer.name] >> Sent: Monday, December 03, 2007 1:31 PM >> To: Daniel Brown >> Cc: Andi Gutmans; intern...@lists.php.net >> Subject: Re: [PHP-DEV] Garbage collector patch
>> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1
>> Hi,
>> Daniel Brown wrote: >>> I don't know about how it worked for anyone else, but the tables >>> didn't display properly on Gmail, so I had a hard time keeping up >> with >>> the performance differences. If you have this in a separate file, >>> could you send it to me as an attachment? >> Same problem, all in one row, to "table" to read. We're having >> non-apache application which run up to one hour to do their task and I >> think our QA can test the new GC there (and memory consumption is an >> issue there definitely).
>> thanks >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
+/* {{{ proto int gc_collect_cycles(void) + Forces collection of any existing garbage cycles. + Returns number of freed zvals */ +ZEND_FUNCTION(gc_collect_cycles) +{ + RETURN_LONG(gc_collect_cycles(TSRMLS_C)); +} +/* }}} */ + +/* {{{ proto void gc_enabled(void) + Returns status of the circular reference collector */ +ZEND_FUNCTION(gc_enabled) +{ + RETURN_BOOL(GC_G(gc_enabled)); +} +/* }}} */ + +/* {{{ proto void gc_enable(void) + Activates the circular reference collector */ +ZEND_FUNCTION(gc_enable) +{ + zend_alter_ini_entry("zend.enable_gc", sizeof("zend.enable_gc"), "1", sizeof("1")-1, ZEND_INI_USER, ZEND_INI_STAGE_RUNTIME); +} +/* }}} */ + +/* {{{ proto void gc_disable(void) + Deactivates the circular reference collector */ +ZEND_FUNCTION(gc_disable) +{ + zend_alter_ini_entry("zend.enable_gc", sizeof("zend.enable_gc"), "0", sizeof("0")-1, ZEND_INI_USER, ZEND_INI_STAGE_RUNTIME); +} +/* }}} */
/* {{{ proto int func_num_args(void) Get the number of arguments that were passed to the function */ Index: Zend/zend_execute.c =================================================================== RCS file: /repository/ZendEngine2/zend_execute.c,v retrieving revision 1.716.2.12.2.24.2.8 diff -u -p -d -r1.716.2.12.2.24.2.8 zend_execute.c --- Zend/zend_execute.c 22 Nov 2007 13:27:11 -0000 1.716.2.12.2.24.2.8 +++ Zend/zend_execute.c 23 Nov 2007 12:33:00 -0000 @@ -64,7 +64,7 @@ static void zend_extension_fcall_end_han
- if (EG(ze1_compatibility_mode)) { - return; + if (Z_REFCOUNT_PP(zval_ptr) == 1) { + if ((*zval_ptr)->type == IS_OBJECT) { + if (EG(ze1_compatibility_mode)) { + return; + } } + Z_UNSET_ISREF_PP(zval_ptr); } - Z_UNSET_ISREF_PP(zval_ptr); + + GC_ZVAL_CHECK_POSSIBLE_ROOT(*zval_ptr); } } /* }}} */ Index: Zend/zend_gc.c =================================================================== RCS file: Zend/zend_gc.c diff -N Zend/zend_gc.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ Zend/zend_gc.c 23 Nov 2007 12:33:00 -0000 @@ -0,0 +1,515 @@ +/* + +----------------------------------------------------------------------+ + | Zend Engine | + +----------------------------------------------------------------------+ + | Copyright (c) 1998-2007 Zend Technologies Ltd. (http://www.zend.com) | + +----------------------------------------------------------------------+ + | This source file is subject to version 2.00 of the Zend license, | + | that is bundled with this package in the file LICENSE, and is | + | available through the world-wide-web at the following
...
Daniel Brown wrote: > I don't know about how it worked for anyone else, but the tables > didn't display properly on Gmail, so I had a hard time keeping up with > the performance differences. If you have this in a separate file, > could you send it to me as an attachment?
Same problem, all in one row, to "table" to read. We're having non-apache application which run up to one hour to do their task and I think our QA can test the new GC there (and memory consumption is an issue there definitely).
thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----Original Message----- > From: Daniel Brown [mailto:paras...@gmail.com] > Sent: Monday, December 03, 2007 1:21 PM > To: Andi Gutmans > Cc: intern...@lists.php.net > Subject: Re: [PHP-DEV] Garbage collector patch >=20 > On Dec 3, 2007 4:01 PM, Andi Gutmans <a...@zend.com> 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
>=20 > Andi, >=20 > I don't know about how it worked for anyone else, but the tables > didn't display properly on Gmail, so I had a hard time keeping up with > the performance differences. If you have this in a separate file, > could you send it to me as an attachment? I have a few real-world > benchmarks I'd like to try from the angle of the shared-webhost > industry (lots of users with horrible code running simultaneously, et > cetera) which I'd like to compare to your notes. >=20 > Thanks. >=20 > -- > Daniel P. Brown > [office] (570-) 587-7080 Ext. 272 > [mobile] (570-) 766-8107 >=20 > If at first you don't succeed, stick to what you know best so that you > can make enough money to pay someone else to do it for you.
I didn't think it would work on the list, but I figured if Andi either sent it to me, or clicked Reply-All, either way it would be delivered directly to my inbox, which it was. So now it's here: http://www.pilotpig.net/pdfs/
-- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107
If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you.
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.
=20
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.
=20
The revised patch has the following advantages: - It fixes several crash bugs
- Enhances performance by removing several unnecessary checks=20 - 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).
=20
We have tested both PHP_5_3 without any patches, the original patch and the new patch.
=20
The following table shows execution time (seconds for N requests) and slowdown.
=20
PHP_5_3
Original GC patch=20
Current GC patch
=20
=20
slowdown
=20
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
=20
PHP_5_3
Original GC patch
Current GC patch
=20
=20
overhead
=20
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%
=20
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.
=20
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.
=20
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.
=20
Thanks to David & Dmitry for working hard on this (and everyone else who contributed).
=20
The stage is open for ideas/thoughts/suggestions J
If for some reason the PDF attachment didn't come through to you on the list, let me know and I'll upload it to one of my servers for you to download and use, as well.
On Dec 3, 2007 4:40 PM, Daniel Brown <paras...@gmail.com> wrote:
> > > On Dec 3, 2007 4:01 PM, Andi Gutmans <a...@zend.com> 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
> > > Andi,
> > > I don't know about how it worked for anyone else, but the tables > > > didn't display properly on Gmail, so I had a hard time keeping up with > > > the performance differences. If you have this in a separate file, > > > could you send it to me as an attachment? I have a few real-world > > > benchmarks I'd like to try from the angle of the shared-webhost > > > industry (lots of users with horrible code running simultaneously, et > > > cetera) which I'd like to compare to your notes.
> > > Thanks.
> > > -- > > > Daniel P. Brown > > > [office] (570-) 587-7080 Ext. 272 > > > [mobile] (570-) 766-8107
> > > If at first you don't succeed, stick to what you know best so that you > > > can make enough money to pay someone else to do it for you.
> --
> Daniel P. Brown > [office] (570-) 587-7080 Ext. 272 > [mobile] (570-) 766-8107
> If at first you don't succeed, stick to what you know best so that you > can make enough money to pay someone else to do it for you.
-- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107
If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you.
> 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
Andi,
I don't know about how it worked for anyone else, but the tables didn't display properly on Gmail, so I had a hard time keeping up with the performance differences. If you have this in a separate file, could you send it to me as an attachment? I have a few real-world benchmarks I'd like to try from the angle of the shared-webhost industry (lots of users with horrible code running simultaneously, et cetera) which I'd like to compare to your notes.
Thanks.
-- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107
If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you.
Daniel Brown wrote: > If for some reason the PDF attachment didn't come through to you > on the list, let me know and I'll upload it to one of my servers for > you to download and use, as well.
The PDF didn't make it through for me. Can you upload it?
-- Edward Z. Yang GnuPG: 0x869C48DA HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
> If for some reason the PDF attachment didn't come through to you > on the list, let me know and I'll upload it to one of my servers for > you to download and use, as well.
> On Dec 3, 2007 4:40 PM, Daniel Brown <paras...@gmail.com> wrote: >> That looks great, Andi.
>> Thanks.
>> On Dec 3, 2007 4:38 PM, Andi Gutmans <a...@zend.com> wrote: >>> Sorry about that. Does the attached PDFed screenshot work for you?
>>> Andi
>>>> -----Original Message----- >>>> From: Daniel Brown [mailto:paras...@gmail.com] >>>> Sent: Monday, December 03, 2007 1:21 PM >>>> To: Andi Gutmans >>>> Cc: intern...@lists.php.net >>>> Subject: Re: [PHP-DEV] Garbage collector patch
>>>> On Dec 3, 2007 4:01 PM, Andi Gutmans <a...@zend.com> 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
>>>> Andi,
>>>> I don't know about how it worked for anyone else, but the tables >>>> didn't display properly on Gmail, so I had a hard time keeping up with >>>> the performance differences. If you have this in a separate file, >>>> could you send it to me as an attachment? I have a few real-world >>>> benchmarks I'd like to try from the angle of the shared-webhost >>>> industry (lots of users with horrible code running simultaneously, et >>>> cetera) which I'd like to compare to your notes.
>>>> Thanks.
>>>> -- >>>> Daniel P. Brown >>>> [office] (570-) 587-7080 Ext. 272 >>>> [mobile] (570-) 766-8107
>>>> If at first you don't succeed, stick to what you know best so that you >>>> can make enough money to pay someone else to do it for you.
>> --
>> Daniel P. Brown >> [office] (570-) 587-7080 Ext. 272 >> [mobile] (570-) 766-8107
>> If at first you don't succeed, stick to what you know best so that you >> can make enough money to pay someone else to do it for you.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----Original Message----- > From: Markus Fischer [mailto:mar...@fischer.name] > Sent: Monday, December 03, 2007 1:31 PM > To: Daniel Brown > Cc: Andi Gutmans; intern...@lists.php.net > Subject: Re: [PHP-DEV] Garbage collector patch >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi, >=20 > Daniel Brown wrote: > > I don't know about how it worked for anyone else, but the tables > > didn't display properly on Gmail, so I had a hard time keeping up > with > > the performance differences. If you have this in a separate file, > > could you send it to me as an attachment? >=20 > Same problem, all in one row, to "table" to read. We're having > non-apache application which run up to one hour to do their task and I > think our QA can test the new GC there (and memory consumption is an > issue there definitely). >=20 > thanks > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iD8DBQFHVHWh1nS0RcInK9ARAmPlAJ9XnOzFmLSl8qDxY5bLBfJBcmgqRACfZnsn > R3cFSHfkMpoffq+f5vMxI3g=3D > =3DOkMW > -----END PGP SIGNATURE-----
> Sorry about that. Does the attached PDFed screenshot work for you?
> Andi
> > -----Original Message----- > > From: Daniel Brown [mailto:paras...@gmail.com] > > Sent: Monday, December 03, 2007 1:21 PM > > To: Andi Gutmans > > Cc: intern...@lists.php.net > > Subject: Re: [PHP-DEV] Garbage collector patch
> > On Dec 3, 2007 4:01 PM, Andi Gutmans <a...@zend.com> 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
> > Andi,
> > I don't know about how it worked for anyone else, but the tables > > didn't display properly on Gmail, so I had a hard time keeping up with > > the performance differences. If you have this in a separate file, > > could you send it to me as an attachment? I have a few real-world > > benchmarks I'd like to try from the angle of the shared-webhost > > industry (lots of users with horrible code running simultaneously, et > > cetera) which I'd like to compare to your notes.
> > Thanks.
> > -- > > Daniel P. Brown > > [office] (570-) 587-7080 Ext. 272 > > [mobile] (570-) 766-8107
> > If at first you don't succeed, stick to what you know best so that you > > can make enough money to pay someone else to do it for you.
-- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107
If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you.
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.
> 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
yes, it does, what worries me is the introduction of yet another non-sense ini setting that modified the very engine behaviuor.. I think we all agree that there are way too many of those do we ?
. My
> suggestion is that we make this feature a compile time flag.
My suggestion is not to add any compile time flag, either provide it or dont.
> 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.
People more commonly uses PHP from distributors, in binary form.. they dont usually decide what is enabled or not, so you have to either reccommend this feature or mark it clearly as untrusted, experimental.
such switches only add more complexity, confusion for users and addtional trouble to distributors.
> 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. > ... > 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. > ... > The stage is open for ideas/thoughts/suggestions
I'm really hesitant to even *mention* this idea, but....
Could "alternate" memory management systems be made available via PECL add-ons, or, more to the point: What is the *actual cost and complexity* involved in implementing (possibly many) different user-selectable memory management systems, and what other future benefits/drawbacks might we see by doing such a thing? (GC is big now, but what about memory pools per mod_auth user, or SHM/SEM pools, or tuning amounts of memory per function, etc...)
I will now apologize to everybody who I just made cry, scream, or damage their furniture, as I didn't mean to hurt you, just trying to stimulate ideas.
> -----Original Message----- > From: Ronald Chmara [mailto:r...@Opus1.COM] > Sent: Monday, December 03, 2007 10:06 PM > To: Andi Gutmans > Cc: intern...@lists.php.net > Subject: Re: [PHP-DEV] Garbage collector patch > I'm really hesitant to even *mention* this idea, but.... >=20 > Could "alternate" memory management systems be made available via > PECL add-ons, or, more to the point: > What is the *actual cost and complexity* involved in implementing > (possibly many) different user-selectable memory management systems, > and what other future benefits/drawbacks might we see by doing such a > thing? (GC is big now, but what about memory pools per mod_auth user, > or SHM/SEM pools, or tuning amounts of memory per function, etc...) >=20 > I will now apologize to everybody who I just made cry, scream, or > damage their furniture, as I didn't mean to hurt you, just trying to > stimulate ideas.
Hi Ronald,
PHP 5.2.x already supports the ability to hook in different "page" managers. In PHP 5.3 you can also override the memory allocation functions. However, this would not include garbage collection like algorithms which actually require changes in the core PHP data type such as zvals. In fact the garbage collection adds memory to the basic datatypes which is why I suggested to either always make these changes, or don't make them so that we retain binary compatibility across all builds of PHP. So overriding basic memory allocation functions, yes, ability to provide various GC implementations, no.
>> -----Original Message----- >> From: Ronald Chmara [mailto:r...@Opus1.COM] >> What is the *actual cost and complexity* involved in implementing >> (possibly many) different user-selectable memory management systems, >> and what other future benefits/drawbacks might we see by doing such a >> thing? (GC is big now, but what about memory pools per mod_auth user, >> or SHM/SEM pools, or tuning amounts of memory per function, etc...)
>> I will now apologize to everybody who I just made cry, scream, or >> damage their furniture, as I didn't mean to hurt you, just trying to >> stimulate ideas.
> Hi Ronald,
> PHP 5.2.x already supports the ability to hook in different "page" > managers. In PHP 5.3 you can also override the memory allocation > functions. However, this would not include garbage collection like > algorithms which actually require changes in the core PHP data type > such > as zvals. In fact the garbage collection adds memory to the basic > datatypes which is why I suggested to either always make these > changes, > or don't make them so that we retain binary compatibility across all > builds of PHP. > So overriding basic memory allocation functions, yes, ability to > provide > various GC implementations, no.
Okay, so, without this patch, I can allocate mem, and destroy it, on a per page level, but not on a zval level, and the choice is: a) zval (etc.) destruction with this patch, which has a 5% speed hit at times (varies per test) b) no patch, no change c) something which hasn't been thought of yet?
I'd have to (sadly) ask that anything that slows down PHP by 5%, to improve performance for programmers that, uhm, "leak" or otherwise gobble RAM, that they, uhm, refactor their code as professional programmers.
> On 04.12.2007 06:00, Cristian Rodriguez wrote: > > such switches only add more complexity, confusion for users and > > addtional trouble to distributors.
> ... which I believe are going to enable this flag by default anyway, > because they don't care about performance too much.
> So I agree, either do it or not, yet another engine mode is bad idea.
> -- > Wbr, > Antony Dovgal
> -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, 2007-12-04 at 00:00 -0300, Cristian Rodriguez wrote: > 2007/12/3, Ilia Alshanetsky <i...@prohost.org>: > > I think the patch does have a value,
> yes, it does, what worries me is the introduction of yet another > non-sense ini setting that modified the very engine behaviuor.. I > think we all agree that there are way too many of those do we ?
Yup. :)
> > My > > suggestion is that we make this feature a compile time flag.
> My suggestion is not to add any compile time flag, either provide it or dont.
I have to agree. Either it's in or not. We've had enough trouble with giving too much rope for people already..
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_ =20 significant; of course, everyone is going to whine about it first) and b) is going to be eliminated over time
> First of all big thanks for Dmitry and David for spending time on =20 > this project and continuing to improve the original patch. Based on =20= > the results so far, I think the patch does have a value, but =20 > certainly not in a general case. Relative simple scripts have little =20= > to gain from it and only to loose 3-5% of speed depending on a =20 > situation and given insubstantial memory gains it seems of little =20 > use in general case. That said, there are complex applications =20 > (perhaps unnecessarily so ;-) ) that could see some real benefits =20 > from this code. My suggestion is that we make this feature a compile =20= > time flag, that's off by default and people who feel that their =20 > applications warrant a garbage collector can enable it for their =20 > install and at the same time those who don't (general case) have no =20= > 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 =20 >> amount of >> time in reviewing the garbage collector work and testing it in our >> performance lab. Dmitry has been exchanging ideas and patches with =20= >> 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, =20 >> 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 =20 >> original >> implementation however the data structures have been changed in =20 >> 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 =20 >> have >> yet to find real-life applications that create significant cycles =20 >> 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 =20= >> 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
>> =09
>> 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
>> =09
>> 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 =20 >> guesstimate >> is that you will see even worse results in a 64bit environment). We =20= >> 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 =20 >> hand I >> think now the effort has been made it's a good thing to offer it as =20= >> 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 =20= >> all >> possible bugs.
>> Personally I think the decision should be either in or out. Adding =20= >> 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 =20= >> 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 =20 >> default >> (mainly for stability reasons. Note: the increased memory footprint =20= >> and >> performance loss also exists with the collection itself turned =20 >> off). We >> can turn it on when we're in dev for snapshots so that we iron out =20= >> 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 =20 >> else who >> contributed).
>> The stage is open for ideas/thoughts/suggestions J
>> Andi
> Ilia Alshanetsky
> --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
> You may be right longer term but shorter term I still believe there may be stability issues with this patch some of which we haven't figured out. Although we did testing and found crash bugs I wouldn't trust our level of testing to deem it stable. If we go down the route of always on we could have a hidden ini file (not listed in php.ini-dist and phpinfo()) which we can advise to turn off if something goes wrong and once we can enough confidence that there aren't any lurking bugs we could remove it.
You mean provide an ini setting to be able to turn it Off? But why do you call it "always On" then? And what's the difference comparing to what you've proposed earlier?
Concerning the stability issues, I'd say we have quite good chance to make it stable enough, as (I hope) 5.3.0 is not going to be released for at least several months more.
Companies that are especially concerned of performance/stability are encouraged to step forward and give us a hand.
