That's about it. Is OB heavier than including a file?
+1
A:
Output buffering works in RAM. Hitting the filesystem may only hit RAM (cache), but it has the potential to hit the disks. Any time you hit the disks, you're looking at at least an order of magnitude of slowness compared to straight RAM access.
dkamins
2010-05-15 04:55:36
... as well as tying up the disks and blocking other FS operations and moving the disk head away from areas it's going to need to move back to moments later.
dkamins
2010-05-15 04:56:56
Yes, but I have someone who has proven to be quite knowledgeable saying that the extra USE IN AMOUNT of memory offsets the FS access, making the FS a better option. Thoughts?
Spot
2010-05-15 05:00:45
@Spot, That entirely depends on your system resource constraints. In general, avoid disks. If you do something that causes you to exhaust all RAM and start swapping, then you're not avoiding disks. E.g. output buffering a 30 MB response is different from output buffering a regular web page.
dkamins
2010-05-16 01:56:02
A:
I'd say depends on what's expensive on your system... if you absolutely must use the smallest amount of memory possible, then writing directly to disk may be your only option, although the underlying system's implementation of a 'disk write' will still write out in chunks when it can, since you're probably not calling 'write' for each character.
In the end, buffering within reason is faster... the easiest way to test is by writing out a large string of characters, one character at a time, then the string in a few reasonable chunks.
With that in mind, I can't think of why you wouldn't buffer your output at least somewhat! If all you're doing is copying a file from one place to another, using a system call (if available) is probably much faster than it would be reading, buffering and writing in PHP.
DulabCMS
2010-05-15 07:39:49