Re: [RFC] Performance improvements
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 <dmitry@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
>>
Thread (19 messages)