<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Thu, 23 May 2013 05:07:13 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Larry Garfield's Blog: readfile() not considered harmful]]></title>
      <guid>http://www.phpdeveloper.org/news/17909</guid>
      <link>http://www.phpdeveloper.org/news/17909</link>
      <description><![CDATA[<p>
In <a href="http://www.garfieldtech.com/blog/readfile-memory">this new post</a> to his blog <i>Larry Garfield</i> tries to dispel a common misconception in the PHP development world - that the <a href="http://php.net/readfile">readfile</a> function should be considered harmful and can cause memory issues in your code.
</p>
<blockquote>
If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed. One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." [...] There's just one problem with that age-old truism: It's not true.
</blockquote>
<p>
He created some benchmarks to illustrate the differences between several of the common methods for working with files via the <a href="http://php.net/fread">fread</a>, <a href="http://php.net/fpassthru">fpassthru</a>, <a href="http://php.net/stream_copy_to_stream">stream_copy_to_stream</a> and of course <a href="http://php.net/readfile">readfile</a>. He reports the results based on the runtime and the peak memory usage and noted, ironically, that while the times varied slightly, the memory consumption was exactly the same for all of the approaches. Since there's no real reason not to use "readfile", he looks at three reasons why there might be this stigma attached to it (including the issues that could come up with output buffering enabled).
</p>]]></description>
      <pubDate>Fri, 04 May 2012 09:51:38 -0500</pubDate>
    </item>
  </channel>
</rss>
