|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24362 Performance problem with print on large ammounts of html
Submitted: 2003-06-27 12:39 UTC Modified: 2003-06-28 17:33 UTC
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: grandadmirale at yahoo dot com Assigned:
Status: Not a bug Package: Performance problem
PHP Version: 4.3.2 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: grandadmirale at yahoo dot com
New email:
PHP Version: OS:


 [2003-06-27 12:39 UTC] grandadmirale at yahoo dot com
When using large ammounts of html (printing all at the same time or not) there is a major slowdown while php increases the buffer to allow for more html to be outputted. This is not a bug specific to my software as you can see in example, it should NOT take 1 second to execute phpinfo() when my entire script can (when not using large ammounts of html) execute in 0.05 seconds... if it hits those large ammounts though, the buffer goes up as well as the time, sometimes all the way up to 1 or 2 seconds which is rediculous. IF output_buffering is set high enough in php.ini it runs perfectly fine in the time it should, but since this is not changeable via script it becomes a major problem for scripts that need to output large ammounts of data jumping to multiple seconds of execution time when it should only be a portion of a second.

Reproduce code:
function getmicrotime()
    $time = explode(' ',microtime()); 
    return ((float)$time[0] + (float)$time[1]); 
$timeStart = getmicrotime();
print (getmicrotime() - $timeStart);

Expected result:
It to execute in much under 1 second.

Actual result:
It executes in anywhere from 0.8 seconds to over 1 second.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-27 19:09 UTC]
Took: 0.066812992095947

Nothing wrong here, must be something wrong in your configuration, try copying the php.ini-dist file from the distribution over your php.ini.

 [2003-06-27 20:49 UTC] grandadmirale at yahoo dot com
I can't, I don't run the server, but I've tried it on three seperate servers so far and all have the same result. Two are companies offering hosting, and another is a private server.. they should have correct configurations in their php.ini which leads me to believe that there is some unexpected slowdown when the buffer is increased.
 [2003-06-28 01:55 UTC] neon at neon-line dot net
Took: 0.010692954063416
Not a bug, check if you server is under heavy load etc..
 [2003-06-28 08:16 UTC]
Does the server's have "session.use_trans_sid" enabled?
(check with e.g. 'echo ini_get("session.use_trans_sid");' or from phpinfo() output)

 [2003-06-28 09:11 UTC] grandadmirale at yahoo dot com
Yes, the two servers I tested on have sessionn.use_trans_sid enabled, I am unsure of the third since it is not my server.

Neon, two of the three servers tested on have next to no traffic, server load is not a possibility. ESPECIALLY since the slowdown is consistant, happens every time at the same point.
 [2003-06-28 15:25 UTC]
Are you using session.use_trans_sid if so that would explain the performance drop. Since php would need to buffer the entire output of the script and pass it through a parser that would add a session id to every URL. This would explain why outputing longer text would get progressively slower.
 [2003-06-28 16:23 UTC] grandadmirale at yahoo dot com
Yes it's on... but would it really slow it down THAT MUCH? I will try turning it off on one of the servers tested on, but this becomes a problem since it's not an option for people to turn it off since it's not changeable via script... which might be a good thing to change, I don't really see it presenting a problem, any good php script adds the sessid itself to the url anyways.
 [2003-06-28 16:26 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

Yes it would. Not only does it force increased memory allocation but is also causes parser to go through the data. This can be quite slow, while on a small output couple of kb it may be too small to notice on large files you'll definately feel the impact. If you don't like the performance loss disable that option.
This is not a bug.
 [2003-06-28 16:29 UTC] grandadmirale at yahoo dot com
That's the thing though, as a script writer I can't disable that option, I don't see why it's not setable by script, all other session options are. Sure I can distribute a message saying to ask your host to disable this if it's on, but that's not very effective.
 [2003-06-28 17:27 UTC] grandadmirale at yahoo dot com
Turning it off does NOT fix this problem.
 [2003-06-28 17:31 UTC]
Without buffering this script runs quickly.  There is no bug here.
 [2003-06-28 17:33 UTC] grandadmirale at yahoo dot com
And yet without buffering on three different servers it doesn't run quickly, which would imply a bug especially if for some it runs fine and others it doesn't.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Jun 19 23:01:23 2021 UTC