Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33599
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.198.189 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=TZ5gWiwhPUehRoO4WCqblGISoGXq0m6ZBMfmyhzuYPBTzUB5yuAdfwloUaDeAFurXulWV7nGIggkGkGCI4LXtD4zZmEPn+YRqQSPb9C8mwGeMKYV6JZVpQkPIcxYiNBxcAq8Gb19S+zbh/Nzmp4Uou+5RR2AL7auMTk6+F5tKWQ=
Message-ID: <ab5568160712031340v3c0cc358l34e2519a2137fa15@mail.gmail.com>
Date: Mon, 3 Dec 2007 16:40:27 -0500
To: "Andi Gutmans" <andi@zend.com>
Cc: internals@lists.php.net
In-Reply-To: <698DE66518E7CA45812BD18E807866CEF89000@us-ex1.zend.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net>
	 <ab5568160712031321r762e020cw58ef28a5984132b1@mail.gmail.com>
	 <698DE66518E7CA45812BD18E807866CEF89000@us-ex1.zend.net>
Subject: Re: [PHP-DEV] Garbage collector patch
From: parasane@gmail.com ("Daniel Brown")

    That looks great, Andi.

    Thanks.

On Dec 3, 2007 4:38 PM, Andi Gutmans <andi@zend.com> wrote:
> 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 patch
> >
> > On Dec 3, 2007 4:01 PM, Andi Gutmans <andi@zend.com> 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.