Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33595
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.198.188 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=GRqfjeOoN7xHd4WPdML6YBz8odpTLCrlPdOIIXRUFLO7e9b8eKqviraqS0zPyB0ArA7noo5NavV4Q/rbclb+QiaP0va8ZvOZW6wPf9bSj9c3eqnN9YT1EcuRW3LSHr3/stq2+qpghDgTzOJcQK3IRwwY6tLYb3CRp6AQzvZlOjg=
Message-ID: <ab5568160712031321r762e020cw58ef28a5984132b1@mail.gmail.com>
Date: Mon, 3 Dec 2007 16:21:15 -0500
To: "Andi Gutmans" <andi@zend.com>
Cc: internals@lists.php.net
In-Reply-To: <698DE66518E7CA45812BD18E807866CEF88FDD@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>
Subject: Re: [PHP-DEV] Garbage collector patch
From: parasane@gmail.com ("Daniel Brown")

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.