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