ID: 23836 Updated by: [EMAIL PROTECTED] Reported By: webmaster at maczsoftware dot com -Status: Open +Status: Bogus Bug Type: Output Control Operating System: RedHat Linux 8.0 PHP Version: 4.3.2RC4 New Comment:
Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Using gzhandler caused the entire output of your page to be buffered in memory before being sent to the user. If you are outputing large amount of text this process would involve quite a few memory reallocation calls not to mention the compression overhead. While it may be unnoticeable on small pages that do no generate a lot of output on large pages you'll definately feel the performance loss. Previous Comments: ------------------------------------------------------------------------ [2003-05-28 00:56:47] webmaster at maczsoftware dot com Since this issue needs an external XML file (to be parsed) to produce such a problem, I've included it also. Script and XML file are packed in one package (113 KB): http://www.maczsoftware.com/files/misc/ ob_start_performance.tar.gz To reproduce the issue just run the script (tunes.php) without any modifications. ob_start() takes several seconds to run. The call to ob_start is located at tunes.php at line 32. This script tells itself about time consumption at the end of the produced HTML data. ------------------------------------------------------------------------ [2003-05-27 17:26:23] [EMAIL PROTECTED] Please provide a complete but short and self-contained example script which we can try ourselves. ------------------------------------------------------------------------ [2003-05-27 12:02:17] webmaster at maczsoftware dot com I'm having some pretty weird issues with ob_start() function. I have a merely complex script, which parses XML file (its functionality is located in own class, which is included from another php file). Because this script can output pretty much data, I'm buffering the output and then send it to browser gzipped. However, the execution time of my script is 23 seconds with large XML file, so I started to investigate possibilities of optimization. I thought - of course - that XML parsing was taking too long, but when I started to count seconds with getmicrotime() function, I found out that ob_start("ob_gzhandler") was taking 14 seconds of that 23! So I suppose this could be a bug in the PHP. I'm not saying that the script is too slow, 23 secs can be completely possible, but that calling getmicrotime() right before and right after ob_start() and getting 14 secs can't be right. All data is printed after ob_start() call, and at the end of the script ob_end_flush() is called. I have also tried using non-gzipped output, with pretty same processing time. The code which relates to this problem is below: Code: $before = getmicrotime(); ob_start("ob_gzhandler"); $after = getmicrotime(); // Here comes some XML parsing and printing some large text data // ... print "Time usage for ob_start: " . ($after - $before) . " seconds\n"; ob_end_flush(); // This is standard getmicrotime from php.net function getmicrotime() { list($usec, $sec) = explode(" ",microtime()); return ((float)$usec + (float)$sec); } --- PHP INFO: PHP 4.3.2RC4 (cli) (built: May 22 2003 16:30:41) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies Configure line: ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-gd --with-zlib-dir=/usr/local --enable-memory-limit ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=23836&edit=1
