Recently Chad Kieffer made a post to his blog about a handy little feature of the Eclipse IDE that can help you speed up your development - snippets and templatings.

You already know that Eclipse PDT provides autocompletion and hints for PHP's built in functions. In addition, commenting your code with PHPDoc adds autocompletion and hinting for your application's classes, methods, and variables. If you haven't already discovered, Eclipse PDT also provides autocompletion of PHP's control structures, class definitions, and methods through code templates.

He gives examples of both the templating and the snippets - inserting a switch() statement template and how to create a custom snippet of whatever code you choose.

PHPEveryDay.com has posted several new tutorials on a wide range of topics recently - here's some of them:

• CakePHP Installation: Quick Start - a tutorial about how to install CakePHP framework
• CakePHP Installation: Introduction - a tutorial with a CakePHP Introduction
• PHP Supported Metacharacters (You Must Know Them) - a reference about metacharacters and metasequences
• HTML Filters/Purifiers, The Need, and Introducing htmLawed - using htmLawed and purifying your HTML
• Speed Up Web Page Loading

Check out the rest of the site for more great tutorials and articles.

Etienne Kneuss has posted about a new part of the Standard PHP Library that creates arrays that are up to thirty percent faster than normal methods - SplFastArray.

Antony got the idea to implement a C-like array wrapper in SPL: SplFastArray. The main advantage of that class is performance, it's indeed faster than PHP arrays. How so? No free lunch: The speedup comes from the fact that non-numeric indexes are not allowed and that the array is of fixed size.

The code sample shows the setting of the size for the array (and changing it) with a var_dump of the output result. This method is always faster than normal arrays, it just varies how much from system to system (anywhere from ten to thirty percent).

Sebastian Bergmann quickly points out a patch that Derick Rethans committed to the XDebug software to make things a bit more usable:

Derick recently committed a patch that improves the performance of code coverage data collection in Xdebug. [...] This makes PHPUnit's code coverage functionality so much more practical to use.

Two examples of it in action are included - one for XDebug 2.0.0 and the other for the development version, XDebug 2.0.1-dev.

In a new entry to his blog, Fabian has posted a patch he's developed help get things running faster with Symfony and Propel:

I found the sfBuilders that are responsible for stripping the comments from the generated propel classes and also saw that there is a addIncludes parameter in propel.ini. Lets reuse that and modify the Builders to strip the inline includes and requires.

What he describes as a "tiny step" can help you squeeze that much more performance out of your Symfony application. You can download the patch file here.

Tobias Schlitt offers a helpful hint or two for "speeding up" your application in the form of comparison operators.

The fact that type save comparisons (ala ===) are faster in PHP than the normal comparison operator (ala ==). The reason for this is simply, that PHPs loosly-typed-ness-auto-cast-code is not even touched with ===

He also points out an interesting condition that saves a bit of computing time - comparing the isset() of a variable to true over the count() to zero. Some of his benchmarking (code) shows this in action.

Travis Swicegood, after having been asked to do a review of the Zend_Log component of the Zend Framework, wrote up his report and has also posted it to his blog.

The short answer to is Zend_Log good (enough): yes; the long answer, no. First off, it does what it needs to do without too much fuss [...] but... It has a few fatal flaws in my opinion.

While he found the simplicity of the component nice, the flaws seemed to outweigh the good. Problems like code redundancy and a simple thing like writing out to the log file isn't handled well (can't be accessed directly, only through the interface - slower in the long run?). He's included some tests to check out the difference.

Greg Beaver has blogged about an enhancement in the latest release of phar (1.2.1) - a major speed boost:

A few minutes ago, I released phar version 1.2.1. phar is a PHP extension that allows the creation of complete filesystems within a single physical file. In addition, a bootstrap stub written in PHP can be used to run a phar archive as if it were an executable file or shell script. Documentation on its usage and how to create phars is at http://php.net/phar in the PHP manual.

Greg mentions some other issues that were fixed and a refactoring of some of the stream operations to cut the speed in half.

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.

On the symfony blog today, there's a new article looking to dispel some misunderstanding that's come up surrounding the speed of symfony applications and what effect it can have in a real-world situation.

We regularly see framework benchmarks pop up somewhere on the net, comparing symfony to other frameworks, either in PHP or in other languages. The conclusion of some of them is "symfony takes more time than other frameworks to display a 'hello, world', which makes it unsuitable for real-world web applications".

If some benchmarks show that symfony is slower, jumping to the conclusion that symfony is not optimized is a big mistake. [...] If symfony is well implemented (or so we think), then its speed is just the sum of the individual speeds of all the features it includes. Or, to put it differently, Symfony's speed is the consequence of a series of choices that we made to decide whether a feature should or should not make it to the core.

They suggest that the speed of symfony applications does not come as a result of the main portion of the framework, but rather as a choice of the development team as to what parts they wanted to include in the core and what not to. They also point out that, while speed does matter somewhat, especially in larger applications, it shouldn't be highest on the list.