We wanted to share some of our insights on the performance patches.
Roman did some tests on the Doctrine 2 performance testsuite to check the benefits of the performance improvements and they are pretty impressive (Thanks Dimitry!). Our performance testsuite containts pretty intense and heavy PHP looping, array and string crunching tests with very few to none calls to external libraries using a mocked database along the lines of "how long does php take to transform 10000 database rows into an object structure". See his mail initially sent to the doctrine-dev list: Hi, I already shared this info with some of the core developers but thought it might be of interest to anyone subscribed to this group. I just wanted to share some results I got with testing out the new performance improvements committed to PHP trunk recently. See: http://wiki.php.net/rfc/performanceimprovements I don't know whether all improvements mentioned in the Wiki have been committed yet, at least interned strings seem to be committed, but the results are already pretty good: Running: Doctrine/Tests/ORM/Performance/AllTests.php ; PHP 5.3.3-dev (SQLite in-memory) snapshot testSimpleQueryScalarHydrationPerformance10000Rows - 0.19897103309631 seconds .testSimpleQueryArrayHydrationPerformance10000Rows - 0.39269518852234 seconds .testMixedQueryFetchJoinArrayHydrationPerformance10000Rows - 0.85220384597778 seconds .testSimpleQueryPartialObjectHydrationPerformance10000Rows - 0.74572706222534 seconds .testSimpleQueryFullObjectHydrationPerformance10000Rows - 2.8694489002228 seconds .testMixedQueryFetchJoinPartialObjectHydrationPerformance2000Rows - 0.32160806655884 seconds .testMixedQueryFetchJoinFullObjectHydrationPerformance2000Rows - 0.61252403259277 seconds . Inserted 10000 objects in 3.828871011734 seconds ; PHP trunk (SQLite in-memory) snapshot testSimpleQueryScalarHydrationPerformance10000Rows - 0.16227412223816 seconds .testSimpleQueryArrayHydrationPerformance10000Rows - 0.27942895889282 seconds .testMixedQueryFetchJoinArrayHydrationPerformance10000Rows - 0.60481095314026 seconds .testSimpleQueryPartialObjectHydrationPerformance10000Rows - 0.58688807487488 seconds .testSimpleQueryFullObjectHydrationPerformance10000Rows - 2.249853849411 seconds .testMixedQueryFetchJoinPartialObjectHydrationPerformance2000Rows - 0.24576616287231 seconds .testMixedQueryFetchJoinFullObjectHydrationPerformance2000Rows - 0.46355390548706 seconds . Inserted 10000 objects in 2.773432970047 seconds The whole test suite runs noticeably faster, I would think at least 30-40%. Memory usage of the complete suite goes down by 10MB (32bit system): 5.3.3-dev: 39 MB 5.x trunk: 29.5 MB On Tue, 20 Apr 2010 15:29:21 +0400, Dmitry Stogov <dmi...@zend.com> wrote: > Jordi Boggiano wrote: >> On 20.04.2010 12:41, Derick Rethans wrote: >>>>> You're writing that the ZEND_CATCH opcode has to be used with a >>>>> constant >>>>> class name, so how would "catch ( self $e )" be represented in >>>>> op-codes now? >>>> I dropped such possibility. Does someone use it? >>>> For me it looks useless. If it's really necessary I can try not to >>>> drop it. >>> You have a point, it looks quite useless. But of course, I am sure >>> somebody has used this :) >> >> FWIW, Google Code Search returns no such thing as far as I could see, it >> obviously doesn't mean it doesn't exist, but if it triggers a parse >> error or something clear enough to the eventual unlucky guy that did use >> it, I guess it might be an acceptable BC break. > > Of course > > $ sapi/cli/php -n -r 'try {} catch (self $e) {}' > > Fatal error: Bad class name in the catch statement in Command line code > on line 1 > > Thanks. Dmitry. > >> Cheers, >> Jordi >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
