On Dec 3, 2007 4:01 PM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>
>
> Was hoping to send this off earlier but I was travelling for the past
> week and had very limited email access.
>
> As promised in the past few weeks we have spent a significant amount of
> time in reviewing the garbage collector work and testing it in our
> performance lab. Dmitry has been exchanging ideas and patches with David
> Wang during this time. Suffice to say that as I've mentioned in the
> past, memory management is an extremely sensitive piece of PHP, which is
> why it was important for us to review this work in great depth before
> committing it to the code base.
>
>
>
> The updated patch still retains the same algorithm as David's original
> implementation however the data structures have been changed in order to
> work faster and use less memory.
>
>
>
> The revised patch has the following advantages:
> - It fixes several crash bugs
>
> - Enhances performance by removing several unnecessary checks
> - The memory overhead was reduced (from 12 to 4 bytes for each
> heap-allocated zval)
> - The speed of "clean" PHP code (code that doesn't create cycles) was
> improved
> - Additional test cases were created
>
> The end result is a more stable and faster GC patch. That said we have
> yet to find real-life applications that create significant cycles which
> would benefit from this patch. In fact as you'll see from the results
> our tests show an increase in maximum memory use and slower execution
> (to be fair they are marginal).
>
>
>
> We have tested both PHP_5_3 without any patches, the original patch and
> the new patch.
>
>
>
> The following table shows execution time (seconds for N requests) and
> slowdown.
>
>
>
> PHP_5_3
>
> Original GC patch
>
> Current GC patch
>
>
>
>
>
> slowdown
>
>
>
> slowdown
>
> bench
>
> 11,550
>
> 12,310
>
> 6,58%
>
> 12,170
>
> 5,37%
>
> hello
>
> 8,781
>
> 8,852
>
> 0,81%
>
> 8,813
>
> 0,36%
>
> xoops
>
> 128,500
>
> 135,100
>
> 5,14%
>
> 130,200
>
> 1,32%
>
> static
>
> 18,540
>
> 20,840
>
> 12,41%
>
> 18,920
>
> 2,05%
>
> qdig
>
> 29,320
>
> 30,270
>
> 3,24%
>
> 29,610
>
> 0,99%
>
> qdig2
>
> 13,960
>
> 14,100
>
> 1,00%
>
> 14,090
>
> 0,93%
>
> The next table shows memory usage in MB and overhead
>
>
>
> PHP_5_3
>
> Original GC patch
>
> Current GC patch
>
>
>
>
>
> overhead
>
>
>
> overhead
>
> hello
>
> 13,750
>
> 13,945
>
> 1,42%
>
> 13,765
>
> 0,11%
>
> xoops
>
> 18,036
>
> 18,636
>
> 3,33%
>
> 18,568
>
> 2,95%
>
> static
>
> 15,300
>
> 16,000
>
> 4,58%
>
> 15,308
>
> 0,05%
>
> qdig
>
> 14,820
>
> 15,008
>
> 1,27%
>
> 14,828
>
> 0,05%
>
> qdig2
>
> 14,824
>
> 15,012
>
> 1,27%
>
> 14,838
>
> 0,09%
>
>
>
> To summarize the patch lead to approx. 5% slowdown and 3% memory
> overhead for typical applications (as always, you mileage may vary
> depending on your system's architecture and OS although my guesstimate
> is that you will see even worse results in a 64bit environment). We also
> tested SugarCRM to get another sanity for these results and we got
> similar results.
>
>
>
> I am not quite sure where this leaves us with this patch. On one hand I
> think now the effort has been made it's a good thing to offer it as part
> of PHP. The downside is of course some performance degradation and
> possible instabilities as this patch continues to stabilize (it took
> about two releases for us to stabilize the Zend Memory Manager even
> after in-depth testing due to edge cases in allocation patterns and
> various extensions, etc...).I'd be surprised if our team has found all
> possible bugs.
>
>
>
> Personally I think the decision should be either in or out. Adding this
> as a compile option is not a good idea as it would create binary
> compatibility issues and would be a pain for the community. I think my
> inclination is to commit the patch, not have it #ifdef'ed but always
> compiled but to have the garbage collection itself turned off by default
> (mainly for stability reasons. Note: the increased memory footprint and
> performance loss also exists with the collection itself turned off). We
> can turn it on when we're in dev for snapshots so that we iron out bugs.
> That said, as you can see from the results most people and real-life
> applications will be worse off than today.
>
>
>
> Thanks to David & Dmitry for working hard on this (and everyone else who
> contributed).
>
>
>
> The stage is open for ideas/thoughts/suggestions J
>
>
> Andi
>
>
Andi,
I don't know about how it worked for anyone else, but the tables
didn't display properly on Gmail, so I had a hard time keeping up with
the performance differences. If you have this in a separate file,
could you send it to me as an attachment? I have a few real-world
benchmarks I'd like to try from the angle of the shared-webhost
industry (lots of users with horrible code running simultaneously, et
cetera) which I'd like to compare to your notes.
Thanks.
--
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107
If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
