#50351 [Ver]: performance regression handling objects, ten times slower in 5.3.x than in 5.2

[jani]

 ID:   50351
 Updated by:   j...@php.net
 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:

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.




Previous Comments:


[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..



[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.




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 [Ver]: performance regression handling objects, ten times slower in 5.3.x than in 5.2

[jani]

 ID:   50351
 Updated by:   j...@php.net
 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:

See also bug #48781 (propably related as well)


Previous Comments:


[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