<p>Most of my PHP apps have an ob_start at the beginning, runs through all the code, and then outputs the content, sometimes with some modifications, after everything is done.</p>

<pre><code>ob_start()
//Business Logic, etc
header-&gt;output();
echo apply_post_filter(ob_get_clean());
footer-&gt;output();
</code></pre>

<p>This ensures that PHP errors get displayed within the content part of the website, and that errors don't interfere with <code>header</code> and <code>session_*</code> calls.</p>

<p>My only problem is that with some large pages PHP runs out of memory. How do I stop this from happening?</p>

<p>Some ideas:</p>

<ol>
<li>Write all of the buffered content to a temporary file and output that.</li>
<li>When the buffers reaches a certain size, output it. Although this might interfere with the post filter.</li>
<li>Raise the memory limit (thanx @troelskn).</li>
</ol>

<p>Whats the drawbacks on each of these approaches? Especially raising the memory limit?</p>

Can't you raise the memory limit? Sounds like the best solution to me.
Edit: Obviously, raising the memory limit just because a script tops out should raise some red flags, but it sounds to me like this is a legitimate case - eg. the script is actually producing rather large chunks of output. As such, you have to store the output
somewhere
, and memory seems to be the best pick, for both performance and convenience reasons.
I should note also that the memory limit setting is just that - a limit. Scripts that don't consume much memory, won't consume more just because you raise the limit. The main reason for its existence, is to prevent misbehaving/buggy scripts from taking down the entire server. This is something that is important if you have a lot of amateurs hacking away on a shared host (Something PHP has been used a lot for). So if this is your own server, or at least you generally know what you're doing, there isn't really any benefit from having a low memory-limit.