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
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
improvedAdditional 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_3Original 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_3Original 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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Daniel Brown wrote:
I don't know about how it worked for anyone else, but the tablesdidn'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
iD8DBQFHVHWh1nS0RcInK9ARAmPlAJ9XnOzFmLSl8qDxY5bLBfJBcmgqRACfZnsn
R3cFSHfkMpoffq+f5vMxI3g=
=OkMW
-----END PGP SIGNATURE
That'd be great.
Dmitry, David, can you please send the updated patch to the list?
Andi
-----Original Message-----
From: Markus Fischer [mailto:markus@fischer.name]
Sent: Monday, December 03, 2007 1:31 PM
To: Daniel Brown
Cc: Andi Gutmans; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hi,
Daniel Brown wrote:
I don't know about how it worked for anyone else, but the tablesdidn'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.orgiD8DBQFHVHWh1nS0RcInK9ARAmPlAJ9XnOzFmLSl8qDxY5bLBfJBcmgqRACfZnsn
R3cFSHfkMpoffq+f5vMxI3g=
=OkMW
-----END PGP SIGNATURE
attached.
Dmitry.
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:markus@fischer.name]
Sent: Monday, December 03, 2007 1:31 PM
To: Daniel Brown
Cc: Andi Gutmans; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hi,
Daniel Brown wrote:
I don't know about how it worked for anyone else, but the tablesdidn'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.orgiD8DBQFHVHWh1nS0RcInK9ARAmPlAJ9XnOzFmLSl8qDxY5bLBfJBcmgqRACfZnsn
R3cFSHfkMpoffq+f5vMxI3g=
=OkMW
-----END PGP SIGNATURE
Sorry about that. Does the attached PDFed screenshot work for you?
Andi
-----Original Message-----
From: Daniel Brown [mailto:parasane@gmail.com]
Sent: Monday, December 03, 2007 1:21 PM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patchHi 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
improvedAdditional 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_3Original 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_3Original 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 tablesdidn'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-8107If 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.
That looks great, Andi.
Thanks.
Sorry about that. Does the attached PDFed screenshot work for you?
Andi
-----Original Message-----
From: Daniel Brown [mailto:parasane@gmail.com]
Sent: Monday, December 03, 2007 1:21 PM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patchHi 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
improvedAdditional 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_3Original 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_3Original 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 tablesdidn'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-8107If 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.
Markus,
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.
That looks great, Andi. Thanks.Sorry about that. Does the attached PDFed screenshot work for you?
Andi
-----Original Message-----
From: Daniel Brown [mailto:parasane@gmail.com]
Sent: Monday, December 03, 2007 1:21 PM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patchHi 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
improvedAdditional 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_3Original 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_3Original 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 tablesdidn'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-8107If 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-8107If 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 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 ]]
Argh. Here you go: http://cvs.php.net/~andi/GC_email.pdf
-----Original Message-----
From: Edward Z. Yang [mailto:edwardzyang@thewritingpot.com]
Sent: Monday, December 03, 2007 1:43 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patchDaniel 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 ]]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
yes exactly, there was no PDF attachment. Interestingly the signature
was a separate attachment ...
thanks
-
- Markus
Daniel Brown wrote:
Markus, If for some reason the PDF attachment didn't come through to youon the list, let me know and I'll upload it to one of my servers for
you to download and use, as well.That looks great, Andi. Thanks.Sorry about that. Does the attached PDFed screenshot work for you?
Andi
-----Original Message-----
From: Daniel Brown [mailto:parasane@gmail.com]
Sent: Monday, December 03, 2007 1:21 PM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patchHi 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
improvedAdditional 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_3Original 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_3Original 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 tablesdidn'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-8107If 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-8107If 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
iD8DBQFHVHi/1nS0RcInK9ARAp4KAKDKG2s1T4JZgPlAQJpsQsj7iVoSqACfQ9qt
2aF9QsCyV1tGU02vYInHQNU=
=AUjQ
-----END PGP SIGNATURE
Sorry about that. Does the attached PDFed screenshot work for you?
If only we knew how to publish documents on that 'web thing.........
(-:
S
Sorry about that. Does the attached PDFed screenshot work for you?
No, as you can't attach files here....
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Sorry about that. Does the attached PDFed screenshot work for you?
No, as you can't attach files here....
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
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.
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.
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
improvedAdditional 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
2007/12/3, Ilia Alshanetsky ilia@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 ?
. 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.
my 2CLP.
such switches only add more complexity, confusion for users and
addtional trouble to distributors.
FWIW, amen to that.
- Steph
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
I believe this has to be done and it should be always on.
Having less headache is good. I will find other ways to speed up my projects
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--
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
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.
Andi
-----Original Message-----
From: Antony Dovgal [mailto:tony@daylessday.org]
Sent: Tuesday, December 04, 2007 12:28 AM
To: Cristian Rodriguez
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patchsuch 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
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.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
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.
Companies concerned about performance aren't going to use it at all. A
5% hit is significant given that it doesn't fix anything that a company
already concerned about performance/stability cares about. Super leaky
or recursively allocating scripts have long since been weeded out of
those code bases, so it is a 5% performance hit with no gain.
I am not arguing that it isn't useful in the general case. It will make
PHP more robust on loosely controlled servers for what amounts to only a
small penalty, but at the same time it is an easy 5% win for people with
dedicated servers running well-written code.
-Rasmus
I think having it configurable is a must. Turning it on / off via a compile flag will not suit everyone.
Eg - I have a situation where I would not want to run garbage collection for web pages served off my server due to the performance hit, however I also have a CLI script which I run to do complex, but repetitive tasks for ~half an hour.
Now this is not really a big deal to me as I managed to rid most of the leaks by nulling out cyclic references, however that took a lot of work which could have been avoided by this.
Could I suggest also enabling it by default for CLI?
SCOTT MCNAUGHT
Software Developer
Synergy 8 / +617 3397 5212
scott.mcnaught@synergy8.com
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Wednesday, 5 December 2007 5:17 AM
To: Antony Dovgal
Cc: Andi Gutmans; Cristian Rodriguez; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
Antony Dovgal wrote:
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.
Companies concerned about performance aren't going to use it at all. A
5% hit is significant given that it doesn't fix anything that a company
already concerned about performance/stability cares about. Super leaky
or recursively allocating scripts have long since been weeded out of
those code bases, so it is a 5% performance hit with no gain.
I am not arguing that it isn't useful in the general case. It will make
PHP more robust on loosely controlled servers for what amounts to only a
small penalty, but at the same time it is an easy 5% win for people with
dedicated servers running well-written code.
-Rasmus
scott.mcnaught@synergy8.com wrote:
I think having it configurable is a must. Turning it on / off via a compile flag will not suit everyone.
Looking at the code, that isn't really possible. You could have a
switch to turn off the collection, but that won't get you your
performance back. To avoid the performance penalty you need it to be a
compile-time decision.
I only see 2 possible workable solutions here:
-
Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to care
about the binary compatibility issue since they are the same people who
build all their own stuff. -
Drop it
-Rasmus
- Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to care
about the binary compatibility issue since they are the same people who
build all their own stuff.
Note that breaking BC is not only about performance - one your build is
not the same as mainstream PHP, you can't use any binary extension which
would do anything non-performance-related - like interfacing some
external system/library, debugging, profiling, testing, security and so on.
Any commercial module won't be available for the user of this switch,
and all open-source modules one'd have to build by oneself, which may be
serious maintenance issue. I know there are a bunch of companies that
compile PHP with their own options but still use commercial modules,
including both performance and non-performance ones. They couldn't use
this compile switch.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
- Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to care
about the binary compatibility issue since they are the same people who
build all their own stuff.Note that breaking BC is not only about performance - one your build is
not the same as mainstream PHP, you can't use any binary extension which
would do anything non-performance-related - like interfacing some
external system/library, debugging, profiling, testing, security and so on.
Any commercial module won't be available for the user of this switch,
and all open-source modules one'd have to build by oneself, which may be
serious maintenance issue. I know there are a bunch of companies that
compile PHP with their own options but still use commercial modules,
including both performance and non-performance ones. They couldn't use
this compile switch.
Yes, I know what binary compatibility means.
-Rasmus
Stanislav Malyshev wrote:
- Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to
care
about the binary compatibility issue since they are the same people
who
build all their own stuff.Note that breaking BC is not only about performance - one your build
is
not the same as mainstream PHP, you can't use any binary extension
which
would do anything non-performance-related - like interfacing some
external system/library, debugging, profiling, testing, security and
so on.
Any commercial module won't be available for the user of this
switch,
and all open-source modules one'd have to build by oneself, which
may be
serious maintenance issue. I know there are a bunch of companies
that
compile PHP with their own options but still use commercial modules,
including both performance and non-performance ones. They couldn't
use
this compile switch.Yes, I know what binary compatibility means.
Call me crazy, but...
Would it be possible to hard-code the bit that adds the 4 bytes to the
zval, but make the execution bit a flag so that binary compatibility
is always there, but the executable code that does the GC can come or
go as needed?...
Or am I just talking nonsense due to ignorance?
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
Richard,
zval is such a common PHP structure that in a scope of a single script
(even a trivial one) you'd have thousands of them. Therefor even an
extra 4 bytes matter, and for people with large application it would
matter even more. I wish the patch was such that it had no impact on
the people who don't need it, but the reality is that for anyone who
does not need gc cycles, it'll be a performance (speed & memory)
penalty. This is why I had intimately suggested making it a compile
time, configuration option.
Stanislav Malyshev wrote:
- Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to
care
about the binary compatibility issue since they are the same people
who
build all their own stuff.Note that breaking BC is not only about performance - one your build
is
not the same as mainstream PHP, you can't use any binary extension
which
would do anything non-performance-related - like interfacing some
external system/library, debugging, profiling, testing, security and
so on.
Any commercial module won't be available for the user of this
switch,
and all open-source modules one'd have to build by oneself, which
may be
serious maintenance issue. I know there are a bunch of companies
that
compile PHP with their own options but still use commercial modules,
including both performance and non-performance ones. They couldn't
use
this compile switch.Yes, I know what binary compatibility means.
Call me crazy, but...
Would it be possible to hard-code the bit that adds the 4 bytes to the
zval, but make the execution bit a flag so that binary compatibility
is always there, but the executable code that does the GC can come or
go as needed?...Or am I just talking nonsense due to ignorance?
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?--
Ilia Alshanetsky
Hi Ilia,
I suggest more people test the performance difference because as you can
see for us it was negligible. From my experience you see bigger
deviations just by moving kernels, compilers, and even small patches
which affect where in memory the code segments sit, etc...
Maybe some people here who have performance harnesses (I'm sure Yahoo!
has one) could test it too.
Andi
-----Original Message-----
From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Saturday, December 08, 2007 9:35 AM
To: ceo@l-i-e.com
Cc: Rasmus Lerdorf; Stas Malyshev; scott.mcnaught@synergy8.com;
'Antony
Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patchRichard,
zval is such a common PHP structure that in a scope of a single script
(even a trivial one) you'd have thousands of them. Therefor even an
extra 4 bytes matter, and for people with large application it would
matter even more. I wish the patch was such that it had no impact on
the people who don't need it, but the reality is that for anyone who
does not need gc cycles, it'll be a performance (speed & memory)
penalty. This is why I had intimately suggested making it a compile
time, configuration option.Stanislav Malyshev wrote:
- Always compile it in but leave undocumented #ifdefs in place
for
performance freaks. Those same performance freaks aren't going
to
care
about the binary compatibility issue since they are the same
people
who
build all their own stuff.Note that breaking BC is not only about performance - one your
build
is
not the same as mainstream PHP, you can't use any binary extension
which
would do anything non-performance-related - like interfacing some
external system/library, debugging, profiling, testing, security
and
so on.
Any commercial module won't be available for the user of this
switch,
and all open-source modules one'd have to build by oneself, which
may be
serious maintenance issue. I know there are a bunch of companies
that
compile PHP with their own options but still use commercial
modules,
including both performance and non-performance ones. They couldn't
use
this compile switch.Yes, I know what binary compatibility means.
Call me crazy, but...
Would it be possible to hard-code the bit that adds the 4 bytes to
the
zval, but make the execution bit a flag so that binary compatibility
is always there, but the executable code that does the GC can come
or
go as needed?...Or am I just talking nonsense due to ignorance?
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?--
Ilia Alshanetsky
Sorry to intrude on this one!
It seems that some real hard work has gone into this, and a big thanks
from the community for all your hard work.
Can the gc patch feasibly be improved any more? If so surely the time
scales involved with improving further would mean it'd miss the boat for
a 5.3.x release..?
Real-life use of PHP has to be the foremost concideration; in the
production environment, especially on server farms and shared hosts, how
many of them are going to be upgraded to 5.3 anyways, and when so, not
for a long time (sadly)! 4 bytes vs the earlier 12 bytes is a
significant improvement, and much as this may seem a terrible thing to say..
Roll it out in 5.3, turned on by default (with option to disable at
compile time) - that's your test right there, if there are problems then
have it disabled by default in the subsequent minor release.
My only (and major) concern as an end developer is the 5% slowdown and
3% memory overhead, exactly what benefit am I as an end developer going
recieve for this?
Andi started this series with : "On one hand I think now the effort has
been made it's a good thing to offer it as part of PHP"; and I for one
agree, with the emphasis on offer.
Many Regards & Apologies for the intrusion.
Nathan
Andi Gutmans wrote:
Hi Ilia,
I suggest more people test the performance difference because as you can
see for us it was negligible. From my experience you see bigger
deviations just by moving kernels, compilers, and even small patches
which affect where in memory the code segments sit, etc...
Maybe some people here who have performance harnesses (I'm sure Yahoo!
has one) could test it too.Andi
-----Original Message-----
From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Saturday, December 08, 2007 9:35 AM
To: ceo@l-i-e.com
Cc: Rasmus Lerdorf; Stas Malyshev; scott.mcnaught@synergy8.com;
'Antony
Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patchRichard,
zval is such a common PHP structure that in a scope of a single script
(even a trivial one) you'd have thousands of them. Therefor even an
extra 4 bytes matter, and for people with large application it would
matter even more. I wish the patch was such that it had no impact on
the people who don't need it, but the reality is that for anyone who
does not need gc cycles, it'll be a performance (speed & memory)
penalty. This is why I had intimately suggested making it a compile
time, configuration option.Stanislav Malyshev wrote:
- Always compile it in but leave undocumented #ifdefs in place
for
performance freaks. Those same performance freaks aren't going
to
care
about the binary compatibility issue since they are the same
people
who
build all their own stuff.
Note that breaking BC is not only about performance - one your
build
is
not the same as mainstream PHP, you can't use any binary extension
which
would do anything non-performance-related - like interfacing some
external system/library, debugging, profiling, testing, security
and
so on.
Any commercial module won't be available for the user of this
switch,
and all open-source modules one'd have to build by oneself, which
may be
serious maintenance issue. I know there are a bunch of companies
that
compile PHP with their own options but still use commercial
modules,
including both performance and non-performance ones. They couldn't
use
this compile switch.
Yes, I know what binary compatibility means.
Call me crazy, but...Would it be possible to hard-code the bit that adds the 4 bytes to
the
zval, but make the execution bit a flag so that binary compatibility
is always there, but the executable code that does the GC can come
or
go as needed?...Or am I just talking nonsense due to ignorance?
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?--
Ilia Alshanetsky
A few weeks ago I wrote a message on this list about my patch for scalar
type hinting. I've been using it for about a month now in a large scale
application im developing with no problems. It allows type hinting for
the following types: int, float, string, bool (boolean), num (int or
float), scalar (int, float, string, or bool), object, and resource.
All of these types have been very useful. Num has been useful for any
mathematical functions, scalar has been the most useful, mostly for
echoing values and interacting with the database (as a database cant
store arrays or objects).
The type hinting is all 100% optional and has caused no problems for me
at all, I use it in most function but some functions I'll use it for one
parameter and not the other, or none at all with no problems.
What is the general opinion on this? Examples below:
<?php
function multiply(num $a, num b) {
return $a * $b ;
}
multiply(5, 1) ; // works
multiply(3.7, 8.2) // works
multiply("foo", 5) ; // Catchable fatal error: Argument 1 passed to
multiply() must be a number, string given
function displayStuff(scalar $stuff) {
echo $stuff ;
}
displayStuff('Hello!') ; // works
displayStuff(123) ; // works
displayStuff(array('a' => 'b')) ; // Catchable fatal error: Argument 1
passed to displayStuff() must be a scalar, array given
?
Sam Barrow schrieb:
What is the general opinion on this?
I am all for it.
And i think you (or someone else) had it combined with overloading, wich
would be a quite nice extra benefit.
--
Chris
Sam Barrow schrieb:
What is the general opinion on this?
I'm all for it.
Would be using it already, if it where available as an extension.
Do i recall right, that you (or someone else) had this combined with
overloading?
--
Chris
I didn't do anything with overloading, just this.
Also, due to its functionality, it's not something that can be made into
an extension, it would have to go directly into the php source.
I have the patch if you want it, let me know. I've been using it for
almost a month now with PHP 5.3 with no problems.
Sam Barrow schrieb:
What is the general opinion on this?
I'm all for it.
Would be using it already, if it where available as an extension.Do i recall right, that you (or someone else) had this combined with
overloading?--
Chris
Also, due to its functionality, it's not something that can be made into
an extension, it would have to go directly into the php source.
http://pecl.php.net/package/params
http://pecl.php.net/package/SPL_Types
Could you please show us the respect of doing a bit of a research on
the topic you are posting?
Be it type hinting, namespaces or whatever. It is getting very
annoying seeing you resurrect topics that have been declined million
times before.
If you keep this up you risk being ignored on whatever topic you may
bring up, even if its totally valid.
-Hannes
Sam Barrow schrieb:
A few weeks ago I wrote a message on this list
Please do not start a new discussion by replying to a posting that
belongs to a previous thread. This, too, has been written on the list.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For the record, I'm all for it. Optionality means flexibility. If one
doesn't want to use it, he doesn't have to.
Can you send a patch against 5.3 in CVS?
Have you thought about type hinting for return values?
thanks,
-
- Markus
Sam Barrow wrote:
A few weeks ago I wrote a message on this list about my patch for scalar
type hinting. I've been using it for about a month now in a large scale
application im developing with no problems. It allows type hinting for
the following types: int, float, string, bool (boolean), num (int or
float), scalar (int, float, string, or bool), object, and resource.All of these types have been very useful. Num has been useful for any
mathematical functions, scalar has been the most useful, mostly for
echoing values and interacting with the database (as a database cant
store arrays or objects).The type hinting is all 100% optional and has caused no problems for me
at all, I use it in most function but some functions I'll use it for one
parameter and not the other, or none at all with no problems.What is the general opinion on this? Examples below:
<?php
function multiply(num $a, num b) {
return $a * $b ;
}multiply(5, 1) ; // works
multiply(3.7, 8.2) // works
multiply("foo", 5) ; // Catchable fatal error: Argument 1 passed to
multiply() must be a number, string givenfunction displayStuff(scalar $stuff) {
echo $stuff ;
}displayStuff('Hello!') ; // works
displayStuff(123) ; // works
displayStuff(array('a' => 'b')) ; // Catchable fatal error: Argument 1
passed to displayStuff() must be a scalar, array given?>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHXv8e1nS0RcInK9ARApVaAJ9vwTTVdH+HNENA64wfaPbkyCyG9gCgrMuy
CD2xQpN43p0dlgPIiYm2Ckg=
=ZOm7
-----END PGP SIGNATURE
- Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to care
about the binary compatibility issue since they are the same people who
build all their own stuff.
I am all for this.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
2007/12/3, Ilia Alshanetsky ilia@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..
--
Patches/Donations: http://pecl.php.net/~jani/
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.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
improvedAdditional 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
--
--
David Zülke
dz@bitxtender.com
Tel: +49 (0)89 57 08 15 15
bitXtender GbR
Paul-Heyse-Straße 6
80336 München
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
GC is not really useful to 95% of the users either, so is 5% of the
users important or not?
b) is going to be eliminated over time
What is going to be eliminated, the slowdown? How?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
What about binary compatibility?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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.
...
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.
-Ronabop
-----Original Message-----
From: Ronald Chmara [mailto:ron@Opus1.COM]
Sent: Monday, December 03, 2007 10:06 PM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
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.
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.
Andi
-----Original Message-----
From: Ronald Chmara [mailto:ron@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.
Thanks for clearing it up for me, Andi.
-Bop
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.
In the general scope, Ron, you're correct. Where I think this
could really shine is on a shared hosting server, where you may have
dozens - even hundreds - of small, novice web sites, all "programmed
real good-like".
--
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.
The revised patch has the following advantages:
- It fixes several crash bugs
So far, my tests only see new crash bugs... :/
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2ba1140c6930 (LWP 21108)]
0x00000000008be4fe in zend_std_read_property (object=0x1d7f670, member=0x1e3a1e8, type=0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_object_handlers.c:338
338 property_info = zend_get_property_info(zobj->ce, member, (zobj->ce->__get != NULL) TSRMLS_CC);
(gdb) bt
#0 0x00000000008be4fe in zend_std_read_property (object=0x1d7f670, member=0x1e3a1e8, type=0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_object_handlers.c:338
#1 0x0000000000907fd2 in zend_fetch_property_address_read_helper_SPEC_UNUSED_CONST (type=0, execute_data=0x7fff9c73ffa0)
at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:16282
#2 0x00000000009081ca in ZEND_FETCH_OBJ_R_SPEC_UNUSED_CONST_HANDLER (execute_data=0x7fff9c73ffa0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:16304
#3 0x00000000008c4694 in execute (op_array=0x1e17c70) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#4 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c740df0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#5 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c740df0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#6 0x00000000008c4694 in execute (op_array=0x1dce4e0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#7 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c741450) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#8 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c741450) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#9 0x00000000008c4694 in execute (op_array=0x1e17dc0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#10 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c741c80) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#11 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c741c80) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#12 0x00000000008c4694 in execute (op_array=0x1de1a70) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#13 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c743bb0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#14 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c743bb0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#15 0x00000000008c4694 in execute (op_array=0x1d69390) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#16 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c745550) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#17 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c745550) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#18 0x00000000008c4694 in execute (op_array=0x1a20250) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#19 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c7459b0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#20 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c7459b0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#21 0x00000000008c4694 in execute (op_array=0x1a18ed0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#22 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c746340) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#23 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c746340) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#24 0x00000000008c4694 in execute (op_array=0x1a38be0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#25 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c7472e0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#26 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c7472e0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#27 0x00000000008c4694 in execute (op_array=0x11b5430) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#28 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c7475d0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#29 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c7475d0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#30 0x00000000008c4694 in execute (op_array=0x1a38a90) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#31 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c747800) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#32 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c747800) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#33 0x00000000008c4694 in execute (op_array=0x1a4f700) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#34 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c748650) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#35 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c748650) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#36 0x00000000008c4694 in execute (op_array=0x1a4f5b0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#37 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c7494a0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#38 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c7494a0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#39 0x00000000008c4694 in execute (op_array=0x1804ab0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#40 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c74a2f0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#41 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c74a2f0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#42 0x00000000008c4694 in execute (op_array=0x12a5b20) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#43 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c74c7c0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#44 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c74c7c0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#45 0x00000000008c4694 in execute (op_array=0x10e5c40) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#46 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c74dcd0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#47 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c74dcd0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#48 0x00000000008c4694 in execute (op_array=0x10f1520) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#49 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c74e090) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#50 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c74e090) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#51 0x00000000008c4694 in execute (op_array=0x10a5f10) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#52 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c74e5b0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
#53 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c74e5b0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
#54 0x00000000008c4694 in execute (op_array=0x10a5480) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
#55 0x00000000008979b6 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend.c:1159
#56 0x0000000000837d68 in php_execute_script (primary_file=0x7fff9c750b90) at /home/derick/dev/php/php-5.3dev-gc/main/main.c:2011
#57 0x0000000000937234 in main (argc=3, argv=0x7fff9c750dc8) at /home/derick/dev/php/php-5.3dev-gc/sapi/cli/php_cli.c:1140
bt-full:
#0 0x00000000008be4fe in zend_std_read_property (object=0x1d7f670, member=0x1e3a1e8, type=0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_object_handlers.c:338
zobj = (zend_object *) 0x547
tmp_member = (zval *) 0x0
retval = (zval **) 0x273caf0
rv = (zval *) 0x0
property_info = (zend_property_info *) 0x7fff9c73f5f0
silent = 0
#1 0x0000000000907fd2 in zend_fetch_property_address_read_helper_SPEC_UNUSED_CONST (type=0, execute_data=0x7fff9c73ffa0)
at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:16282
offset = (zval *) 0x1e3a1e8
opline = (zend_op *) 0x1e3a198
container = (zval *) 0x1d7f670
retval = (zval **) 0x7fff9c73fb68
#2 0x00000000009081ca in ZEND_FETCH_OBJ_R_SPEC_UNUSED_CONST_HANDLER (execute_data=0x7fff9c73ffa0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:16304
No locals.
#3 0x00000000008c4694 in execute (op_array=0x1e17c70) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
execute_data = {opline = 0x1e3a198, function_state = {function = 0x1e17c70}, fbc = 0x0, called_scope = 0x0, op_array = 0x1e17c70, object = 0x0,
Ts = 0x7fff9c73f660, CVs = 0x7fff9c73f640, original_in_execution = 1 '\001', use_heap = 0 '\0', symbol_table = 0x1e9bb90, prev_execute_data = 0x7fff9c740df0,
old_error_reporting = 0x0}
#4 0x00000000008c4dec in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9c740df0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
original_return_value = (zval **) 0x7fff9c741060
opline = (zend_op *) 0x1e1b428
current_scope = (zend_class_entry *) 0x1dcd560
current_called_scope = (zend_class_entry *) 0x1dcd560
current_this = (zval *) 0x1d7f670
should_change_scope = 1 '\001'
ex_object = (zval *) 0x0
#5 0x00000000008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fff9c740df0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
No locals.
#6 0x00000000008c4694 in execute (op_array=0x1dce4e0) at /home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
execute_data = {opline = 0x1e1b428, function_state = {function = 0x1e17c70}, fbc = 0x0, called_scope = 0x0, op_array = 0x1dce4e0, object = 0x1d7f670,
Ts = 0x7fff9c740188, CVs = 0x7fff9c740140, original_in_execution = 1 '\001', use_heap = 0 '\0', symbol_table = 0x1e5fea0, prev_execute_data = 0x7fff9c741450,
old_error_reporting = 0x0}
To reproduce, run the Template tests of the eZ Components:
mkdir ezc
cd ezc
svn co http://svn.ez.no/svn/ezcomponents/trunk
svn co http://svn.ez.no/svn/ezcomponents/scripts
./scripts/setup-env.sh
php UnitTest/src/run-tests.php Template
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
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).
Does that slowdown result from housekeeping tasks alone that are a
prerequisite for GCing or does it include running the new algorithm?
Is it possible to always perform (unconditionally compile in) the
necessary housekeeping tasks but stick with the current GC, so that
cycle-detection only happens when the user calls a gc_go_find_cycles()
function? Would that significantly improve the above numbers?
-mp.
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).Does that slowdown result from housekeeping tasks alone that are a
prerequisite for GCing or does it include running the new algorithm?Is it possible to always perform (unconditionally compile in) the
necessary housekeeping tasks but stick with the current GC, so that
cycle-detection only happens when the user calls a gc_go_find_cycles()
function? Would that significantly improve the above numbers?
Yes, that would be possible, but it wouldn't speed anything up in case
you don't have any cycles.
Derick
Is it possible to always perform (unconditionally compile in) the
necessary housekeeping tasks but stick with the current GC, so that
cycle-detection only happens when the user calls a
gc_go_find_cycles()
function? Would that significantly improve the above numbers?Yes, that would be possible, but it wouldn't speed anything up in case
you don't have any cycles.
Not sure I got you right. That is, the speed penalty comes from housekeeping? Does the new GC try to find cycles automatically whenever a refcount goes down to zero?
If building and maintaining data structures for the algorithm costs only a little memory but speed impact is neglegible unless the algorithm actually runs, then you could stick with the non-cycle-detecting "legacy" GC (= speed) unless you know you have cycles and/or want to trade a little processing time (a call to gc_go_find_cycles()) for the memory it will/might free.
-mp.
Is it possible to always perform (unconditionally compile in) the
necessary housekeeping tasks but stick with the current GC, so that
cycle-detection only happens when the user calls a
gc_go_find_cycles()
function? Would that significantly improve the above numbers?Yes, that would be possible, but it wouldn't speed anything up in case
you don't have any cycles.Not sure I got you right. That is, the speed penalty comes from
housekeeping? Does the new GC try to find cycles automatically
whenever a refcount goes down to zero?
Not immediately... the algorithm should only run when either the root
buffer is full, or the function is run manually.
If building and maintaining data structures for the algorithm costs
only a little memory but speed impact is neglegible unless the
algorithm actually runs, then you could stick with the
non-cycle-detecting "legacy" GC (= speed) unless you know you have
cycles and/or want to trade a little processing time (a call to
gc_go_find_cycles()) for the memory it will/might free.
Yes, exactly. But it's just as easy to turn automatic cleaning as well -
in that case the find cycle algorithm will kick in at some specific
amount of "freed" vars.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org