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

Nick Halstead asks an interesting question on his blog today - "Do faster typists make better coders?"

I have been able to touch type since about age 12 and can manage about 100 words per minute when faced with blocks of text to copy and even faster if I am just writing code. [...] Programming in C meant a lot more typing of parenthesis and a lot more thinking about the structure of the code.

PHP has introduced another set of typing problems with a lot more use of < > and a much higher mixture of variables/functions/parenthesis plus the added bonus of trying to remember a single function from a choice of 3000+.

Several of the comments on the post suggest that it could be helpful to productivity, but shouldn't be focused on too much. After all, what really matters is the programmers skill, right?

Continuing in their "plugin of the week" series, the Symfony blog presents a new plugin that can help to make your Symfony application up to 70 percent faster than it already is.

I'd like to tell you a little success story about using sfOptimizerPlugin. I did many things in my "public" application to optimize performance [and end up having] an average execution time of ~150ms per page, wich leads to ~100ms in the production environment. A little bit slow, I think.

After [installing the plugin and] running $php symfony optimize public staging over the environment, the execution time was reduced by 50ms from ~150ms down to ~90ms, nice. And even the production environment acts faster now, with only ~30ms to serve pages, very nice - 70% faster!

He even suggests using the sfOptimizerPlugin in a cron job on a server to help keep things constantly optimized.

A new post to the SitePoint PHP Blog today (from Paul Annesley) looks briefly at how, with the help of XDebug, you can make your applications lighter and faster.

So we've got potentially slower code, and we can no longer just open up our simple PHP script and follow its execution from the top of the file to the bottom. How do we figure out exactly what's going on inside?

He doesn't go through the installation of XDebug, but he does give an example (complete with screenshots) of how to use it in conjunction with two other applications - WinCacheGrind for Windows users and KCachegrind - to work with the output XDebug produces.

As Mike Potter mentions in his new blog entry, Flash, Flex and PHP just got a great leg up when it comes to using the combination:

Patrick Mineault, who runs the AMFPHP project, has released a new version of AMFPHP 1.9, beta 2 now. However, the real big news in his blog post was the news that there is now a C based AMF extension for PHP.

According to the test data Patrick gives, the speed jump is well worth implementing the different functionality - a 100% boost, in fact, than the standard PHP version of AMFPHP. Check out Patrick's blog for the rest of these amazing stats.

In his latest blog post, Pádraic Brady talks about a "sweeter alternative" to using Smarty for your site's templating - Template Lite.

Use the term Template Engine in a PHP forum and the word "Smarty" will inevitably crop up. I like Smarty but, similar to a few PHP libraries, it's very bloated.

I try to keep my applications lean and mean - small, fast, and adaptable. Unfortunately, Smarty disagrees with my needs. It's bloated design while packing a mighty punch, uses a chunk of memory and processor time I dislike. Since I also develop open source apps which end up on shared hosts, my concerns are even more justified.

Enter Mark Dickenson. Mark is the developer of a Smarty alternative: Template Lite.

He talks about what Template Lite is and what kinds of advantages it has over Smarty, including staying try to its name. Pádraic measures it as not only being faster but also having 50% of the memoery footprint that Smarty does. He seems to favor it for those places when he just needs something light and easy on a site.

PHP Magazine has posted the results from one of their previous polls today - this time asking readers what they think the largest misconception surrounding PHP is.

The International PHP Magazine conducted a poll over the week, asking for your opinion on 'The misconceptions surrounding PHP'. The options provided were:

• Java/ASP/Ruby/Python/Perl/C is better, and faster than PHP
• PHP does not scale well
• PHP has to write/read everything from a database
• PHP does not support shared memory
• PHP is not a compiled language
• PHP can't run for days

The results from the poll showed unanimously that the impression that Java/ASP/Ruby/Python/Perl/C are better and faster than PHP topped the charts. Coming in close are two options - that PHP doesn't scale well and that PHP isn't a compiled language (surprising).

Check out their latest poll for the week asking what the most common security mistake is.

On his Oracle blog today, Christopher Jones has posted a simple howto on getting the feedback the PHP Oracle functions throw when they error, only faster.

When a connection fails, you want to know about it as soon as possible. With Oracle Net there are many ways to configure connection and authentication. For example a connection:

$c = oci_connect("hr", "hr", "abc");

could be evaluated by Oracle 10g as using the Easy Connect syntax to machine "abc" (using the default port and database service) or using a net alias "abc" configured in a tnsnames.ora file.

He includes some settings to add to the sqlnet.ora file to help speed thing along - setting the directory path to enable a different authentication syntax and changing a setting to restrict the types of connect methods the client can try.

To show how it all works together, he gives an example of the tnsnames.ora, sqlnet.ora, environment variables, and the commands he ran to test it all out.

Wez Furlong posts today about a response made to a previous mention of "PHP vs. ASP.NET" in this article from Joe Stagner in this post on his MSDN blog.

From Wez:

Joe's response is perhaps a little pro-Microsoft (you can't really blame him for that--he does work there :-) but the essence of his response rings true; there's nowhere near enough factual data in the OTN article to make a balanced decision one way or the other.

To be fair to Sean (the author of the OTN article), it does say "Opinion" across the top of the page and the byline is "One developer's view of the pros and cons of the two most popular means of building web applications", but it's easy to forget those once you're into the article.

Wez also mentions one of his personal views on the whole debate, basically saying that even if PHP is the faster/more efficient, some situations might do better with an ASP.NET solution (what's the cost of implementation?).

One of the holy grails of web development is to have your pages lost the fastest way possible. People spend hours optimizing images and condensing the amount of data they actually send over the wire to reach this goal. There are, however, other ways to achieve some of the same results, HTTP compression being one of them. For those that aren't familiar with the topic, DevShed has this new article to bright you up to speed.

This article, the first of three parts, shows you how to make PHP pages load faster by showing you how to compress dynamic PHP pages. Techniques covered include using PHP's built-in "gzencode()" function, along with output buffering control functions.

Since PHP offers a powerful built-in library for handling HTTP compressed data, over this series I'll explain the basics of working with HTTP-compressed PHP pages. I'll illustrate, with several code samples, different methods for compressing dynamic PHP pages.

They start with the basics, writing up a simple script to compress the output from a simple PHP file, one that displays records from a "users" database. With that foundation laid, they move on to the heavy stuff - using more than just simple output buffering to speed up those pages. Their new example makes use of the gzip functions in PHP to compress the data even further. A gzip header is passed off to the browser and it pulls it all neatly compressed over to open on the client-side.