PHP output buffering - sounds like a bad idea, is it?
Asked Answered
B

4

29

Just want to pick the experts' brains on php output buffering. There are times when I've wanted to implement it for one reason or another, but have always managed to rearrange my code to get around it.

I avoid using it because it sounds like it'll cost resources. I mean, if they can offer the coder such wonderful flexibility, why don't they always buffer output? The only answer I can come up with is: because not buffering it saves tremendous resources, and with good coding practice you shouldn't need it.

Am I way off here?

Boggle answered 12/10, 2009 at 20:14 Comment(0)
C
23

From my experience, there isn't a significant impact on performance. I also can't find consistent answers on the subject -- some people claim that there is barely any hit against performance, while some say that there is a minor but significant effect. There is even a comment on php.net suggesting that buffering increases performance as compared to multiple output functions, not that I've verified that or anything.

I think the question of whether or not to buffer has more to do with the intended use of your application. Buffering makes a lot of sense if you want to compress the output before sending it, or if you want to control exactly when and where the output takes place in your code. Since it doesn't take that much effort to add buffering, you may as well try it out -- it should be relatively easy to remove it if you need to.

Chinook answered 12/10, 2009 at 20:27 Comment(2)
Wow that's the first I've heard of that... potential increase in performance. You're right, I should play with it, especially while I'm in the development stage.Boggle
There is a logical reason why performance is enhanced - php is not "breaking from the processing", therefore the processing is much faster because it's continuous - same goes for the data transfer itself. Of course it seems like it will use more memory at a time, but it holds it for shorter time. Altough you are probably loading some framwork/library which takes much more, so it should not be a significant difference considering "normal" source code amount output-ed... :-)Counterespionage
S
9

I think the opposite. Not buffering output is a bad idea unless you run into a situation where you really need it. For instance, a script that's going to create huge amounts of output.

In most cases, burning a bunch of programmer time to save some unknown quantity of (cheap) memory sounds like a waste of resources.

Supersensitive answered 12/10, 2009 at 20:19 Comment(4)
There's a thought... use it but have a way to turn it off when output is massive. Good point, man!Boggle
The easiest way to "turn it off" for a script with a lot of output (think some report that sends out a bunch of csv data, or something) is to just ob_end_flush(); up at the top of your script. You can (try to) force output out inside your loop with flush();Supersensitive
Its not cheap memory when you have 20,000 users taking all the resources your server has.Sisco
@MichaelHanon - It's only not-cheap if you think programmer time is free. Your app code is already allocating megabytes of memory (especially if you're using popular frameworks), a few hundred kilobytes of buffered output is unlikely to move the needle.Supersensitive
T
6

If you are in the situation where content is getting output before the headers, you'll need to stuff it in a buffer or else the page will error out that content was output before headers. This has happened to me with shared libraries and not enough time to go in and do a proper fix to get to launch. It's one of those mark a //TODO / FIXME and then go back and make it proper later on.

Trishtrisha answered 12/10, 2009 at 20:27 Comment(0)
J
4

Using output buffering I was able to make a light weight templating system quickly for a home brewed MVC backend for my last PHP project. I love it and find it very useful.

And regarding resources: it's not that resource intensive. If you're worried about the little it uses, PHP is not the right tool for the job. I love PHP but it is NOT the lightest option. On any reasonably modern server though, that won't matter.

Jellicoe answered 12/10, 2009 at 20:22 Comment(3)
@Dinah, I was under the impression that PHP was super lightweight... but that's probably because I'm used to ColdFusion. What's even lighter?Boggle
@Boggle C, or ASM. PHP is such a flexible language that it is usually way slower than any other Desktop language, like C,C++,Java,C# etc. . However, compared to other scripting languages, it can still be pretty fast.Ibson
@Aaron. Lets compare Web Technology with Web Technology: PHP is faster than Python, RoR, Javascript. If you choose Phalcon PHP framework then it is faster than ASP.NET MVC, and Swoole PHP is faster than Node.JS, and also a good fit for IoT / REST / Network Apps. With OpCache you can make it more faster. PHP JIT is part of PHP 8.0 (which is under development at the time of writing). PHP is easy (cost-effective), flexible (for example, in PHP "Strong Data Typing" is optional) and light-weight.Ernie

© 2022 - 2024 — McMap. All rights reserved.