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
