On the SitePoint PHP blog, David Peterson shares some of the comments and thoughts that Rasmus Lerdorf (creator of PHP) had recently on a good range of topics (including frameworks).

This is the fist time I have heard Rasmus Lerdorf speak and it was entertaining to say the least. Refreshing would another way to describe it, I enjoy hearing real opinions and not holding back - Rasmus doesn't hold back.

He talked about frameworks (and why they're not the best thing for the job), how you can make PHP fast (or can you?) and some mention of the semantic web and Drupal.

With the recent stir caused by the new iPhone, it's only natural that developers are looking for easy ways to make their sites as compatible as possible with the mobile platform. The Symfony project has posted a guide to helping you make your apps optimized for mobile use.

symfony 1.1 introduces native support for different formats and mime-types. This means that the same model and controller can have different templates based on the requested format. The default format is still HTML but symfony supports several other formats out of the box as defined in the factories.yml file.

Using this system, it's easy to add new output formats by adding to the default layouts the framework comes equipped with. The Content-Type can be changed and layouts can be disabled as needed. This lets you make a custom definition just for use with the iPhone without a lot of hassle.

They also include an example of how to make one of these optimized layouts, including some iPhone "screenshots" of the resulting pages.

Brian Shire has posted a new tutorial talking about some of the benefits of caching the functionality of your website (with things like APC, not file or database caching):

Opcode caches save energy, expenses, improve overall user experience on web sites, and it's often one of the simplest optimizations to implement. This article will explain the basics of installing, configuring, and tuning an opcode cache for PHP, the Alternative PHP Cache (APC).

The article focuses on how the APC works and how to get it up and working on your installation (as pulled from the pecl repositories). They look at some of the functions the extension's API includes (like ap_cache_info or ap_store for manual caching) as well as some more advanced topics like locking performance, working with TTL, cache priming and filtering.

In this new post to his blog, Ian Selby talks about a method to "pump up" your web site's performance to give the most to your visitors - the APC cache.

Nothing's cooler than writing a bad-ass site or application and watching it gain popularity and a significant user base. By the same token, nothing's more frustrating that watching your app fall on its face when its running under high load. [...] Before you say, "throw more / better hardware at that mo-fo", why not take a moment and learn about APC: Alternative PHP Cache...

He describes the caching software - what it is and how it can help you and your application - and includes examples using a CacheManger class to store and set values quickly and easily.

Reinhold Weber has put together a list of signs (40 in all on his "programming list of shame") that you're a lousy PHP programmer. Here's a sampling:

• don't see the need and/or benefits of a good programming IDE like Zend Studio or Eclipse PDT
• have never used some form of version control like Subclipse
• don't use a consistent methodology
• don't use test-driven development
• don't return content but echo or print it from your functions or classes
• return HTML, not data, strings, or objects.
• don't allow intelligent error handling
• you think reusable software equals/requires your code to be OOP

Now granted, some of them are a bit more high level than others, but if you're not headed towards a lot of these, you might change paths, hop out of that comfort zone and branch out into the community and the language a little bit more.

Based off of a previous article from Mike Willbanks, Stuart Herbert has posted some of his own thoughts on tuning and tweaking your applications for the best performance you can get out of them.

There's some good advice in there, and I thought it'd be a good idea to quickly add a bit more detail about the separate approaches that Mike raises.

He goes over the APC caching, memcache, the "gzip trick", the "Not Modified" header and optimized SQL statements.

He also mentions one thing that Mike didn't mention - a split between static files (no PHP needed) and their dynamic cousins. Having a more pure Apache (no PHP installed) can help give a minute jump in speed that, depending on the size of the site, could really add up from a user's perspective.

On his blog today, Alex Netkachov has posted a suggestion of how to combat a common issue facing PHP scripts - their memory usage.

PHP has a build-in garbage collector so you do not need to track the links on the objects, allocate memory for objects and delete them when they are not longer necessary. Things seem so perfect that developers do not even know that their scripts allocate a lot of memory until their server stops processing requests because of the out of memory error.

His example is the processing of a parent/child relationship tree. If not managed correctly, the variables being used could get out of hand quite quickly. Alex recommends the use of a "destructor" at the end of each iteration to help destroy variables and values no longer needed.

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.

Spurred on by some previous benchmarks [pdf] from Ilia Alshanetsky, Joakim Nygard decided to run some his own benchmarks on the same sort of functionality.

There are numerous discussions in the blogosphere about whether to use echo versus print, if for() is faster than while(), etc. and though the gains are usually very small, I decided to add my thoughts to the debate. I found an article on optimization through coding habits in Ilia Alshanetsky's zend performance slides.

According to his results:

• Calling require_once() 10000 times in a for() loop with an empty file is 4x faster.
• With a simply autoload requiring a class and 10000 loops of new Foo() versus require_once('foo.php'); new Foo() shows that __autoload() is ~3.7 times faster.
• If a class method can be static, declare it static. Speed improvement is by a factor of 4.
• Avoid function calls within for() loop control blocks
• Always, always quote array keys.
• Get rid of 'harmless' error messages - they take time to generate and output.

I am not out to prove Ilia wrong - he knows PHP better than most - and for all I know, they could have optimized those very functions in PHP 5.2. [...] It would appear that there are improvements, albeit small, to achieve from minimal effort. Plus I was surprised by the discrepancies I found compared to Ilia's recommendations.

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.