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