-----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 <[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. >> > > > -----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----- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
