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.
On Dec 3, 2007 4:40 PM, Daniel Brown <[EMAIL PROTECTED]> wrote:
> 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.
>
--
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
