That looks great, Andi.
Thanks.
On Dec 3, 2007 4:38 PM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Sorry about that. Does the attached PDFed screenshot work for you?
>
> Andi
>
>
> > -----Original Message-----
> > From: Daniel Brown [mailto:[EMAIL PROTECTED]
> > Sent: Monday, December 03, 2007 1:21 PM
> > To: Andi Gutmans
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Garbage collector patch
> >
> > 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.
>
--
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
