ID:               37168
 User updated by:  dolecek at sky dot cz
 Reported By:      dolecek at sky dot cz
 Status:           Open
 Bug Type:         WDDX related
 Operating System: Windows, NetBSD
-PHP Version:      5.1.2
+PHP Version:      5.1.4
 New Comment:

I figured I used a malloc() debug option when I run the test on NetBSD
(/etc/malloc.conf -> 'J'), which caused each realloc() call to
explicitly malloc() new piece of memory and free the old. With that
disabled, the WDDX serializer result is much better on NetBSD (this is
without the patch, run with PHP 5.1.4) and actually can complete the
benchmark:

wddx_serialize_value() (without /etc/malloc.conf -> J):
0050:  0.0027
0100:  0.0058
0200:  0.0152
0400:  0.0724
0800:  0.3820
1600:  1.6633
3200:  6.9623
6400: 28.6273

For comparison, this is result with standard serialize():
0050:  0.0016
0100:  0.0032
0200:  0.0092
0400:  0.0275
0800:  0.1174
1600:  0.5613
3200:  2.3775
6400:  9.8372

So, the WDDX serializer still shows strong non-linear behaviour.

wddx_serialize_value() with patch (and without /etc/malloc.conf->J):
0050:  0.0026
0100:  0.0048
0200:  0.0104
0400:  0.0227
0800:  0.0476
1600:  0.0933
3200:  0.1914
6400:  0.3859

serialize() result after applying similar patch to ext/standard/var.c:
0050:  0.0015
0100:  0.0028
0200:  0.0061
0400:  0.0151
0800:  0.0320
1600:  0.0670
3200:  0.1374
6400:  0.2744


Previous Comments:
------------------------------------------------------------------------

[2006-05-23 22:07:24] dolecek at sky dot cz

Changing the OS to Windows, NetBSD.

------------------------------------------------------------------------

[2006-05-02 19:33:16] dolecek at sky dot cz

Fine, the difference is entirely dependant on platform realloc()
implementation. Anyone can try the patch on MS Windows? I don't have
native compiler there. Thanks.

------------------------------------------------------------------------

[2006-05-02 13:36:00] [EMAIL PROTECTED]

I tried your patch on linux 2.6 and MacOSX 10.3.4 and in both 
cases had no visible difference (beyond the margin of error) 
in terms of speed and time taken to execute the code.

------------------------------------------------------------------------

[2006-04-23 21:32:41] dolecek at sky dot cz

Also, it would be useful to know if my patch improves performance on
your system (even though the time increase is linear even without my
patch on your system). Could you include results without and with patch
on your system, please?

------------------------------------------------------------------------

[2006-04-23 21:29:43] dolecek at sky dot cz

I tried the snapshot php5.1-200604232030 - results:

NetBSD 3.99.15 (compiled with ./configure --enable-wddx
--with-libxml-dir=/usr/pkg):
50: 0.010740995407104
100: 0.053707838058472
200: 0.23849892616272
400: 2.4622600078583
800: 18.556435823441
1600: 94.584519863129

(3200 and 6400 skipped)


Tried also Windows version on Windows XP (same computer):
50: 0.0027320384979248
100: 0.0066189765930176
200: 0.024183988571167
400: 0.096118927001953
800: 0.57651996612549
1600: 2.4123661518097
3200: 8.9470641613007
6400: 34.234342098236

So PHP snapshot is ever worse on NetBSD 3.99.15 then PHP 5.1.2. On
Windows XP, the increase is linear, but the time increase is
non-proportional (2x size means ~4x time increase).

What OS did you try the test? Older BSD malloc() was power-of-2
internally and thus would not suffer from this usage pattern. The more
modern version used on NetBSD has been adjusted to minimize total
memory use, which gives the realloc() performance hit in this case.
Perhaps modern GNU libc malloc()/realloc() handles this usage pattern
better and that is the reason you don't see the problem?

BTW, if the patch 2) or it's variant is adopted, it would be useful to
use some suitable power-of-2 value for SMART_STR_START_SIZE (to get
multiple of page size and optimal memory use of last page), rather then
changing SMART_STR_PREALLOC (which is unused in my patch).

------------------------------------------------------------------------

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/37168

-- 
Edit this bug report at http://bugs.php.net/?id=37168&edit=1

Reply via email to