In a new post to his blog Ilia Alshanetsky takes a look at PHP's output buffering feature and some interesting things he found when testing some recent code (hint: it has to do with PHP's "interesting" management of the buffer).

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.

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.

In this recent post to his blog Terry Chay points out one way he (and Tagged) used to help prevent things like "unknown class" errors in their code - lazy loading.

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.

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 another way (as written up by Brian Shire). It uses two settings for APC in your php.ini file and the latest versions of PHP 5.3 & APC along with this patch to make them work.

As Johannes Schluter mentions, the results of some benchmarking have been posted concerning the performance of PHP 5.3 versus the current 5.2 series:

Dmitry posted results of performance test comparing PHP 5.2 and 5.3 to internals which are impressive numbers.

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.

The Internet Super Hero blog points out 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.

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…

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.

Check out the entire post on more about this handy function and the full details of the "behind the scenes" of how it works.

The Internet Super Hero blog points out 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.

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…

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.

Check out the entire post on more about this handy function and the full details of the "behind the scenes" of how it works.

DynamicWebPages.de has posted their new statistics for PHP usage in the community for this past month:

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.

You can check out the graph and the statistics for the last year in their statistics page of their site.

DynamicWebPages.de has posted their new statistics for PHP usage in the community for this past month:

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.

You can check out the graph and the statistics for the last year in their statistics page of their site.

In his latest, Andrei Zmievski talks a bit about an article over on the Ohloh.net website (statistics site that analyzes the source of Open Source applications) titled "PHP Eats Rails for Breakfast".

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).

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. Andrei 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".

Check out the original article for more information on the stats and some charts to show the trends.

In his latest, Andrei Zmievski talks a bit about an article over on the Ohloh.net website (statistics site that analyzes the source of Open Source applications) titled "PHP Eats Rails for Breakfast".

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).

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. Andrei 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".

Check out the original article for more information on the stats and some charts to show the trends.

Jim Plush shares a handy hint he's come upon while working with debug statements in his code - how to speed them up by 85%.

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.

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.

He includes sample code to illustrate along with some of the testing parameters that he followed to get at the 85% mark he did.