Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33640 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 32640 invoked by uid 1010); 4 Dec 2007 14:33:47 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 32623 invoked from network); 4 Dec 2007 14:33:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Dec 2007 14:33:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=dz@bitxtender.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=dz@bitxtender.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain bitxtender.com from 80.237.132.12 cause and error) X-PHP-List-Original-Sender: dz@bitxtender.com X-Host-Fingerprint: 80.237.132.12 wp005.webpack.hosteurope.de Received: from [80.237.132.12] ([80.237.132.12:48221] helo=wp005.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4C/72-09439-84565574 for ; Tue, 04 Dec 2007 09:33:45 -0500 Received: from dslb-084-056-048-121.pools.arcor-ip.net ([84.56.48.121] helo=localhost); authenticated by wp005.webpack.hosteurope.de running ExIM using esmtpsa (TLSv1:RC4-SHA:128) id 1IzYqB-0006PU-4v; Tue, 04 Dec 2007 15:33:39 +0100 Cc: Andi Gutmans , Message-ID: <9AC26FB8-F85B-47DA-A5BC-ACF39DD81F95@bitxtender.com> To: Ilia Alshanetsky In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 4 Dec 2007 15:33:38 +0100 References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net> X-Mailer: Apple Mail (2.915) X-bounce-key: webpack.hosteurope.de;dz@bitxtender.com;1196778825;577bec82; Subject: Re: [PHP-DEV] Garbage collector patch From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=) I could be wrong, of course, but my guess is that the ~3% speed decrease a) is not really significant to 95% of the users (I mean _really_ =20 significant; of course, everyone is going to whine about it first) and b) is going to be eliminated over time david Am 04.12.2007 um 03:43 schrieb Ilia Alshanetsky: > First of all big thanks for Dmitry and David for spending time on =20 > this project and continuing to improve the original patch. Based on =20= > the results so far, I think the patch does have a value, but =20 > certainly not in a general case. Relative simple scripts have little =20= > to gain from it and only to loose 3-5% of speed depending on a =20 > situation and given insubstantial memory gains it seems of little =20 > use in general case. That said, there are complex applications =20 > (perhaps unnecessarily so ;-) ) that could see some real benefits =20 > from this code. My suggestion is that we make this feature a compile =20= > time flag, that's off by default and people who feel that their =20 > applications warrant a garbage collector can enable it for their =20 > install and at the same time those who don't (general case) have no =20= > penalties of having it in place. > > > On 3-Dec-07, at 4:01 PM, Andi Gutmans 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 =20 >> amount of >> time in reviewing the garbage collector work and testing it in our >> performance lab. Dmitry has been exchanging ideas and patches with =20= >> 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, =20 >> 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 =20 >> original >> implementation however the data structures have been changed in =20 >> 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 =20 >> have >> yet to find real-life applications that create significant cycles =20 >> 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 =20= >> 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 >> >> =09 >> >> >> >> 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 >> >> =09 >> >> >> >> 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 =20 >> guesstimate >> is that you will see even worse results in a 64bit environment). We =20= >> 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 =20 >> hand I >> think now the effort has been made it's a good thing to offer it as =20= >> 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 =20= >> all >> possible bugs. >> >> >> >> Personally I think the decision should be either in or out. Adding =20= >> 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 =20= >> 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 =20 >> default >> (mainly for stability reasons. Note: the increased memory footprint =20= >> and >> performance loss also exists with the collection itself turned =20 >> off). We >> can turn it on when we're in dev for snapshots so that we iron out =20= >> 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 =20 >> else who >> contributed). >> >> >> >> The stage is open for ideas/thoughts/suggestions J >> >> >> Andi >> > > Ilia Alshanetsky > > --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- David Z=FClke dz@bitxtender.com Tel: +49 (0)89 57 08 15 15 bitXtender GbR Paul-Heyse-Stra=DFe 6 80336 M=FCnchen