#50351 [Com]: performance regression handling objects, ten times slower in 5.3.x than in 5.2
ID: 50351
Comment by: rlillack at yasni dot de
Reported By: rlillack at yasni dot de
Status: Verified
Bug Type: Scripting Engine problem
Operating System: 64/32bit linux
PHP Version: 5.3.1
New Comment:
It has to do something with object allocation because the problem does
NOT occur with this loop:
foreach (range(1, 100) as $i) {
$a []= array($i);
}
Previous Comments:
[2009-12-02 09:11:20] notarealemail at nodomain dot com
Sorry, forgotten a benchmark:
time: 0.90 secs, memory usage 219.38 MiB. (original loop, GC disabled)
So the problem seems more related to foreach+array+garbage collector
than class allocation
[2009-12-02 08:59:11] j...@php.net
Not exactly faster but better than with foreach():
[j...@localhost ~]$ php -d memory_limit=2G t.php
time: 2.73 secs, memory usage 371.39 MiB.
[j...@localhost ~]$ src/build/php_5_3/sapi/cli/php -d memory_limit=2G
t.php
time: 3.05 secs, memory usage 383.46 MiB.
[2009-12-02 08:42:56] notarealemail at nodomain dot com
Simply changing the loop from
foreach (range(1, 100) as $i)
to
for ( $i = 0; $i < 100; $i++ )
Makes php 5.3.1 (win xp vc9 nots cli) run "normal", even faster than
5.2.11 (same configuration).
Performance (php 5.3.1):
time: 8.23 secs, memory usage 219.38 MiB. (original loop)
time: 0.91 secs, memory usage 219.39 MiB. (modified loop)
time: 0.72 secs, memory usage 219.38 MiB. (modified loop, GC disabled)
Tested on a E8400 3GHz.
[2009-12-01 14:46:39] j...@php.net
See also bug #48781 (propably related as well)
[2009-12-01 13:48:23] rlillack at yasni dot de
This seems to be related to the new cyclic garbage collector trying to
free memory after each allocation?!
A rather simple workaround is to insert gc_disable() before and
gc_enable() after entering the loop.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/50351
--
Edit this bug report at http://bugs.php.net/?id=50351&edit=1
#50351 [Com]: performance regression handling objects, ten times slower in 5.3.x than in 5.2
ID: 50351 Comment by: notarealemail at nodomain dot com Reported By: rlillack at yasni dot de Status: Verified Bug Type: Scripting Engine problem Operating System: 64/32bit linux PHP Version: 5.3.1 New Comment: Sorry, forgotten a benchmark: time: 0.90 secs, memory usage 219.38 MiB. (original loop, GC disabled) So the problem seems more related to foreach+array+garbage collector than class allocation Previous Comments: [2009-12-02 08:59:11] j...@php.net Not exactly faster but better than with foreach(): [j...@localhost ~]$ php -d memory_limit=2G t.php time: 2.73 secs, memory usage 371.39 MiB. [j...@localhost ~]$ src/build/php_5_3/sapi/cli/php -d memory_limit=2G t.php time: 3.05 secs, memory usage 383.46 MiB. [2009-12-02 08:42:56] notarealemail at nodomain dot com Simply changing the loop from foreach (range(1, 100) as $i) to for ( $i = 0; $i < 100; $i++ ) Makes php 5.3.1 (win xp vc9 nots cli) run "normal", even faster than 5.2.11 (same configuration). Performance (php 5.3.1): time: 8.23 secs, memory usage 219.38 MiB. (original loop) time: 0.91 secs, memory usage 219.39 MiB. (modified loop) time: 0.72 secs, memory usage 219.38 MiB. (modified loop, GC disabled) Tested on a E8400 3GHz. [2009-12-01 14:46:39] j...@php.net See also bug #48781 (propably related as well) [2009-12-01 13:48:23] rlillack at yasni dot de This seems to be related to the new cyclic garbage collector trying to free memory after each allocation?! A rather simple workaround is to insert gc_disable() before and gc_enable() after entering the loop. [2009-12-01 13:38:56] j...@php.net My results were done with i686.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50351 -- Edit this bug report at http://bugs.php.net/?id=50351&edit=1
#50351 [Com]: performance regression handling objects, ten times slower in 5.3.x than in 5.2
ID: 50351 Comment by: notarealemail at nodomain dot com Reported By: rlillack at yasni dot de Status: Verified Bug Type: Scripting Engine problem Operating System: 64/32bit linux PHP Version: 5.3.1 New Comment: Simply changing the loop from foreach (range(1, 100) as $i) to for ( $i = 0; $i < 100; $i++ ) Makes php 5.3.1 (win xp vc9 nots cli) run "normal", even faster than 5.2.11 (same configuration). Performance (php 5.3.1): time: 8.23 secs, memory usage 219.38 MiB. (original loop) time: 0.91 secs, memory usage 219.39 MiB. (modified loop) time: 0.72 secs, memory usage 219.38 MiB. (modified loop, GC disabled) Tested on a E8400 3GHz. Previous Comments: [2009-12-01 14:46:39] j...@php.net See also bug #48781 (propably related as well) [2009-12-01 13:48:23] rlillack at yasni dot de This seems to be related to the new cyclic garbage collector trying to free memory after each allocation?! A rather simple workaround is to insert gc_disable() before and gc_enable() after entering the loop. [2009-12-01 13:38:56] j...@php.net My results were done with i686.. [2009-12-01 13:37:27] j...@php.net [j...@localhost ~]$ src/build/php_5_2/sapi/cli/php -n -d memory_limit=2G t.php time: 4.10 secs, memory usage 371.39 MiB. [j...@localhost ~]$ src/build/php_5_3/sapi/cli/php -n -d memory_limit=2G t.php time: 25.97 secs, memory usage 383.46 MiB. [2009-12-01 12:53:42] rlillack at yasni dot de Description: PHP 5.3 did indeed introduce many performance improvements, but we spotted a rather hard regression with handling a large amount of objects that are allocated at the same time. Running the following test case on one of our web servers yield this result with a vanilla build of 5.2.11: time: 1.28 secs, memory usage 376.48 MiB. and this with 5.3.1: time: 13.44 secs, memory usage 400.62 MiB. (command line in both cases: PREFIX/bin/php -d memory_limit=2G testcase.php) The regression at least since the PHP 5.3 release candidates. Both were fresh build straight from the tarball, No extensions, etc. Opcode caches do not help. --with-zend-vm does not help. Reproduce code: --- http://bugs.php.net/?id=50351&edit=1
