Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33602 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3752 invoked by uid 1010); 3 Dec 2007 21:44:34 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 3737 invoked from network); 3 Dec 2007 21:44:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Dec 2007 21:44:34 -0000 Authentication-Results: pb1.pair.com header.from=markus@fischer.name; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=markus@fischer.name; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.49 cause and error) X-PHP-List-Original-Sender: markus@fischer.name X-Host-Fingerprint: 62.179.121.49 viefep31-int.chello.at Solaris 10 (beta) Received: from [62.179.121.49] ([62.179.121.49:52184] helo=viefep31-int.chello.at) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1F/56-02463-0C874574 for ; Mon, 03 Dec 2007 16:44:33 -0500 Received: from genuine.home ([213.47.124.167]) by viefep31-int.chello.at (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP id <20071203214429.BOTD20302.viefep31-int.chello.at@genuine.home>; Mon, 3 Dec 2007 22:44:29 +0100 Received: from chello213047124167.36.11.vie.surfer.at ([213.47.124.167] helo=[192.168.1.51]) by genuine.home with esmtpa (Exim 4.50) id 1IzJms-0001Fr-Mt; Mon, 03 Dec 2007 23:29:16 +0100 Message-ID: <475478BF.5070003@fischer.name> Date: Mon, 03 Dec 2007 22:44:31 +0100 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Daniel Brown CC: Andi Gutmans , internals@lists.php.net References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net> <698DE66518E7CA45812BD18E807866CEF89000@us-ex1.zend.net> In-Reply-To: X-Enigmail-Version: 0.95.5 OpenPGP: id=C2272BD0; url=http://markus.fischer.name/my_public_key.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -16 X-Spam-Level: - X-Spam-Report: Spam detection software, running on the system "genuine.home", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, yes exactly, there was no PDF attachment. Interestingly the signature was a separate attachment ... [...] Content analysis details: (-1.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [213.47.124.167 listed in dnsbl.sorbs.net] -0.4 AWL AWL: From: address is in the auto white-list Subject: Re: [PHP-DEV] Garbage collector patch From: markus@fischer.name (Markus Fischer) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, yes exactly, there was no PDF attachment. Interestingly the signature was a separate attachment ... thanks - - Markus Daniel Brown wrote: > 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 wrote: >> That looks great, Andi. >> >> Thanks. >> >> >> On Dec 3, 2007 4:38 PM, Andi Gutmans 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 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. >> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHVHi/1nS0RcInK9ARAp4KAKDKG2s1T4JZgPlAQJpsQsj7iVoSqACfQ9qt 2aF9QsCyV1tGU02vYInHQNU= =AUjQ -----END PGP SIGNATURE-----