<?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>Tue, 21 May 2013 09:46:35 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Ilia Alshanetsky's Blog: PHP's Output Buffering]]></title>
      <guid>http://www.phpdeveloper.org/news/17230</guid>
      <link>http://www.phpdeveloper.org/news/17230</link>
      <description><![CDATA[<p>
In a new post to his blog <i>Ilia Alshanetsky</i> takes a look at PHP's output buffering feature and some <a href="http://ilia.ws/archives/244-PHPs-Output-Buffering.html">interesting things he found</a> when testing some recent code (hint: it has to do with PHP's "interesting" management of the buffer).
</p>
<blockquote>
While profiling our application I came across a a rather strange memory usage by the ob_start() function. We do use ob_start() quite a bit to defer output of data, which is a common thing in many applications. What was unusual is that 16 calls to ob_start() up chewing through almost 700kb of memory, given that the data being buffered rarely exceeds 1-2kb, this was quite unusual.
</blockquote>
<p>
Through a bit more testing he found that, if a buffer provided for content isn't enough, PHP automatically bumps it up by 10kb each time - a waste of resources if you only need a small subset of that. He includes a small patch he made to the PHP core API that allows for defining a custom buffer size and, if it's not enough, bumps up the buffer size by 1kb instead of 10kb.
</p>]]></description>
      <pubDate>Thu, 08 Dec 2011 10:01:15 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Terry Chay's Blog: Autoloading and Lazy Loading]]></title>
      <guid>http://www.phpdeveloper.org/news/12411</guid>
      <link>http://www.phpdeveloper.org/news/12411</link>
      <description><![CDATA[<p>
In <a href="http://terrychay.com/blog/article/autoloading-and-lazy-loading.shtml">this recent post</a> to his blog <i>Terry Chay</i> points out one way he (and Tagged) used to help prevent things like "unknown class" errors in their code - lazy loading.
</p>
<blockquote>
It's not that Andrei is wrong in his admonition. Far from it! For reasons that I don't quite care to know, there are caching and lookup optimizations that APC cannot do when it has to switch context to run __autoload.
</blockquote>
<p>
They did see a performance boost from the code rewrite it took to make this happen but, since not everyone can take the time to optimize their code like this, he also suggests <a href="http://tekrat.com/2009/03/10/apc-lazy-loading-initial-support/">another way</a> (as written up by <i>Brian Shire</i>). It uses two settings for <a href="http://pecl.php.net/package/APC//">APC</a> in your php.ini file and the latest versions of PHP 5.3 & APC along with <a href="http://tekrat.com/downloads/bits/apc_lazy_php53.patch">this patch</a> to make them work.
</p>]]></description>
      <pubDate>Mon, 27 Apr 2009 11:14:26 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Johannes Schluter's Blog: PHP 5.3: Up to 30% performance win]]></title>
      <guid>http://www.phpdeveloper.org/news/9859</guid>
      <link>http://www.phpdeveloper.org/news/9859</link>
      <description><![CDATA[<p>
As <i>Johannes Schluter</i> <a href="http://schlueters.de/blog/archives/68-PHP-5.3-Up-to-30-performance-win.html">mentions</a>, the results of some benchmarking have been <a href="http://news.php.net/php.internals/36484">posted</a> concerning the performance of PHP 5.3 versus the current 5.2 series:
</p>
<blockquote>
Dmitry <a href="http://news.php.net/php.internals/36484">posted results</a> of performance test comparing PHP 5.2 and 5.3 to internals which are impressive numbers.
</blockquote>
<p>
The improvements were measured based on several popular pieces of software like Drupal, typo3 and WordPress. The overall performance gian was around thirty percent across the board.
</p>]]></description>
      <pubDate>Wed, 26 Mar 2008 10:28:07 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Internet Super Hero: PHP: mysqli_fetch_all()]]></title>
      <guid>http://www.phpdeveloper.org/news/8476</guid>
      <link>http://www.phpdeveloper.org/news/8476</link>
      <description><![CDATA[<p>
The Internet Super Hero blog <a href="http://blog.ulf-wendel.de/?p=154">points out</a> a new MySQL function for PHP (included with the new MySQL native drivers) that automatically does what countless sites currently do with a loop - grab all of the results from a database query and stuff them into a single array.
</p>
<blockquote>
Here is excellent news for you. mysqli_fetch_all(), which comes with mysqlnd, does the task of fetching the data sometimes twice as fast as mysqli_fetch_array(). Reason being: it saves a loop with function calls…
</blockquote>
<p>
The mysqli_fetch_all function allows you to reduce not only code clutter caused by the loops, but also speeds up the process (by 60% according to his findings). This is based on his current setup, though - under different circumstances (and OSes) there were varying results, but none too much off of the 60% mark. The lowest came in at around a 54% increase.
</p>
<p>
Check out <a href="http://blog.ulf-wendel.de/?p=154">the entire post</a> on more about this handy function and the full details of the "behind the scenes" of how it works.
</p>]]></description>
      <pubDate>Fri, 17 Aug 2007 07:59:00 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[DynamicWbePages.de: New PHP Statistics]]></title>
      <guid>http://www.phpdeveloper.org/news/7218</guid>
      <link>http://www.phpdeveloper.org/news/7218</link>
      <description><![CDATA[<p>
DynamicWebPages.de has <a href="http://www.dynamicwebpages.de/99.rdfnews.php?select=1121">posted their new statistics</a> for PHP usage in the community for this past month:
</p>
<blockquote>

After the small decrease in the last month, PHP made it back up easily. For the first time since April 2006, the 20 million mark on the number of domains has been passed. In contrast to the previous month that means a jump of nearly 800,000 domains. The number of IP addresses, on which PHP is installed, also has numbers worth checking out. With 1,332,514 IP addresses on record, this month's numbers are the highest conditions since September 2004.
</blockquote>
<p>
You can check out the graph and the statistics for the last year <a href="http://www.dynamicwebpages.de/60.php-statistiken.php">in their statistics page</a> of their site.
</p>]]></description>
      <pubDate>Mon, 05 Feb 2007 08:49:00 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Andrei Zmievski's Blog: "PHP Eats Rails for Breakfast"]]></title>
      <guid>http://www.phpdeveloper.org/news/6544</guid>
      <link>http://www.phpdeveloper.org/news/6544</link>
      <description><![CDATA[<p>
In his <a href="http://www.gravitonic.com/blog/archives/000195.html">latest</a>, <i>Andrei Zmievski</i> talks a bit about <a href="http://ohloh.net/wiki/articles/php_eats_rails">an article</a> over on the Ohloh.net website (statistics site that analyzes the source of Open Source applications) titled "PHP Eats Rails for Breakfast".
</p>
<blockquote>
So far they've indexed over 3,000 projects and their conclusion seems to be that among Web scripting languages, PHP is the undisputed champion (as measured by the LOC count).
</blockquote>
<p>
He also notes that they've discovered something interesting - despite the lowering numbers of developers/projects being done with PHP, the code and applications seem to be growing still. <i>Andrei</i> interprets this as a positive move for developers away from the "reinvent the wheel" school of thought to a more "find something that works already and go from there".
</p>
<p>
Check out <a href="http://ohloh.net/wiki/articles/php_eats_rails">the original article</a> for more information on the stats and some charts to show the trends.
</p>]]></description>
      <pubDate>Mon, 23 Oct 2006 07:15:04 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Jim Plush's Blog: Do you use debug statements in PHP? Speed them up by 85%]]></title>
      <guid>http://www.phpdeveloper.org/news/6072</guid>
      <link>http://www.phpdeveloper.org/news/6072</link>
      <description><![CDATA[<p>
<i>Jim Plush</i> shares a <a href="http://www.litfuel.net/plush/?postid=143">handy hint</a> he's come upon while working with debug statements in his code - how to speed them up by 85%.
</p>
<blockquote>
<p>
For many of us we have a configuration file for our web applications. In that configuration file there is usually a DEBUG constant that we can turn on to print out helpful debug statements on the screen or to a flat file.
</p>
<p>
If you do something similar to get data from your applications consider adding a test for the debug value before calling the function directly. If you do you'll get about an 85% speed gain when debug is turned off. Which probably will be 98% of the time your application is running.
</p>
</blockquote>
<p>
He <a href="http://www.litfuel.net/plush/?postid=143">includes sample code</a> to illustrate along with some of the testing parameters that he followed to get at the 85% mark he did.
</p>]]></description>
      <pubDate>Thu, 17 Aug 2006 20:45:14 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Nexen.net: PHP Statistics for July 2006]]></title>
      <guid>http://www.phpdeveloper.org/news/5957</guid>
      <link>http://www.phpdeveloper.org/news/5957</link>
      <description><![CDATA[<p>
<i>Damien Seguy</i> has submitted information about the <a href="http://www.nexen.net/chiffres_cles/phpversion/php_statistics_for_july_2006.php">latest PHP statistics</a> for this month for July 2006:
</p>
<blockquote>
<p>
Here are the PHP stats for July 2006. To learn about methodology, read la section phpversion. 15 millions servers were surveyed during May, and 8,1 millions were used for stats: domaines without web sites, those unreachable, ISP or domain parkings were not considered.
</p>
<p>
In brief : 
<ul>
<li>PHP 5 keep on growing, but slower
<li>PHP 5.1.4 is now the most popular PHP 5 version
<li>PHP 4.4.2 is bigger than ever
<li>New : PHP adoption by governements around the world
</ul>
</p>
</blockquote>
<p>
For each of the stats, there's a <a href="http://www.nexen.net/chiffres_cles/phpversion/php_statistics_for_july_2006.php">nice graph</a> of various types to show the distribution and information (such as maps for the spread of PHP's market share all across the world).
</p>]]></description>
      <pubDate>Fri, 04 Aug 2006 11:39:35 -0500</pubDate>
    </item>
  </channel>
</rss>
