On PHPMaster.com today there's a new post from Matthew Turland talking about PHP's quest for performance and some of the recent advancements that have made better performing applications even more possible.

While it's sufficient for many users, as PHP sees increased use by large sites like Wikipedia and Facebook, the ability to serve more requests on fewer servers becomes increasingly important. Some efforts have been made in this area in the last few years, both within and outside the PHP internals team. However, understanding exactly what's going on requires a bit of background both in history and concepts.

He goes through some of the origins of the PHP language (from the early days with Rasmus Lerdorf) to the fact that the PHP language itself is interpreted - complete with some of the overhead that comes with that. He also mentions various projects that have tried to compile PHP back down to C to increase performance like Roadsend, HipHop and, most recently, the HipHop virtual machine from Facebook.

In this recent blog post nikic takes an in-depth look at how large PHP arrays really are - how memory is used in the creation and management of these handy PHP variable types.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage. [...] How much would you expect it to be? [...] Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that's 13.97 MB - eightteen times more than we estimated.

He goes into the details of PHP's memory management and breaks it down into the different totals (for 64 bit and 32 bit OSes) and details on each - zvalue_value, zvalue, cycles collector, Zend MM allocator and the buckets used to isolate one array (hash table/dictionary) from another.

What does this tell us? PHP ain't C. That's all this should tell us. You can't expect that a super dynamic language like PHP has the same highly efficient memory usage that C has. You just can't.

Kristina Chodorow has posted a four part series of articles to her blog that shares some of her experiences in developing an extension for PHP (on C/C++). It walks you through the entire process - from the basic "hello world" out to working with more complex data structures.

A PHP extension allows you to connect almost any C/C++ code you want to PHP. This is a 4-part tutorial on how to write an extension. [...] Almost all of the code examples in this tutorial are available on Github.

The parts of the series cover:

• setting up a PHP environment
• creating a first "hello world" extension
• working with the PHP C API
• creating PHP objects in C (classes)

Each step comes with some good explanation, code samples and some advice on common tasks and pitfalls along the way.

Kevin Schroeder has some of his own thoughts on the recent results of the TIOBE index ranking the popularity of programming languages. PHP has slopped down two spots, replaced by Python and C++. He looks at the data TIOBE has to back it up and can't seem to find a reason why.

I decided to take a look and see what was going on behind the scenes by reading on the index definition to see if I could understand what happened. After reading through the definition I still don't know what happened, or even why it happened.

He goes through how the index data is created - search results from the top 6 hits in Alexa for each language result - and how he, basically, found nothing out of the ordinary. He points out that, because of inconsistencies like this, the TIOBE index shouldn't be regarded as much more than a loose guide. Since it's based on hard-coded search strings, it'll never be a true judge of "popularity" overall.

David Parra has a suggestion for PHP developers out there - it might be beneficial to learn some C so you know what's going on.

I think most of the people using PHP wonder from time to time about particular behavior of the language. [...] But lately I stumbled over a nice one. It looked like a bug in PHP, but turns out to be an interesting, curious, part of the C-language.

He gives an example of a case where an error message (as a result of E_ALL error reporting) shows evaluation of certain variables in a different order than anticipated. As it turns out, the difference was in the order of the parameters in the C code of PHP (different on SPARC versus x86 systems).

On the Zend Developer Zone a new tutorial has been posted looking at taking your pre-existing C++ functionality and wrapping it in a PHP extension to be used directly in your code.

In this tutorial I am going to walk you through creating a PHP extension called "vehicles" which will expose a single class called "Car" (obviously in the real-world, your extensions will expose many classes, but I'm trying to keep things simple). The extension will be built for PHP 5. I am only going to give instructions for building the extension in a UNIX-like environment, although most of what I cover should apply to Windows extension development as well.

The tutorial walks you through everything - how the file layout should look, making a build system, the contents of his files (the sample extension lets you do things to the Car like shift gears and brake) and how to combine the C++ code with the build process to create a shared module you can include right in your php.ini.

A little while back Matthew Turland posted about something that some developers moving over to PHP from more strict languages have an issue with - variable typing - and how its evolved in languages over time.

Without a little background in programming languages or computer science in general, it's entirely possible that typing systems are not something that have crossed your mind. I thought I'd take a blog entry to share some of my thoughts on how it's affecting the creation and evolution of languages.

He walks through history a bit, mentioning C, Java, Python and PHP and how they differ in their default type handling. He especially focuses on the "blurred line" between strong and weak typing and how some if offers special features to the language that uses the method.

In a new post on his blog, Wez Furlong shares some of the materials from a presentation he gave at the PHP Con West back in 2003 on the topic of "Extending PHP".

While poking around the disks in my linux box, I found my materials for a session on extending PHP that I originally gave as a 3 hour tutorial at PHP{Con West 2003.

Sadly, I seem to have lost the working C code (libares bindings for PHP), but all the relevant parts can be found in the comprehensive PDF I made from the slides: Extending PHP Slides (PDF). The content is based on PHP 4, but should still be applicable to PHP 5.

The talk [PDF] covers the creation of a sample DNS resolving library to extend the functionality already in PHP, and includes some of the code examples (in PHP) to show how it all works. This is followed by the C code to build the extension, defining each of the functions, and geting it up and running.

In this latest post from the Professional PHP Blog, there's a brief compaison of PHP versus other languages on a few different points.

Chris Shiflett posted some thoughts on PHP and Ruby on Rails which has generated some interesting discussion. Chris divides programming languages into two categories: Flexible and powerful, Structured and organized.

I prefer to group languages in a different way.

Among the topics to compare the languages under, included are things like garbage collection, interactive or batch, and abstraction. For each, he breaks the category down, describing what it's all about and seperates it into its two components, assigning langauges.

On his blog today, Andi Gutmans has posted his feelings on the growing trend of PHP developers turnng to the C level of things to add new functionality to the PHP development.

One thing I have noticed, is that quite often, PHP developers who are seeking for new PHP features are prematurely trying to implement them in C. Although, there are definitely cases where you want to write your code in C, I think in some cases PHP is too quickly dismissed.

Developing features in PHP not only takes less time, but is also less prone to bugs, easier to maintain, and more stable and secure. Also, in the majority of cases, whether such a feature were implemented in C or PHP, would not make a significant different to overall application performance.

He gives the example of the ZSearch functionality that they mentioned in the php|architect webcast for the Zend framework - entirely implemented in PHP, not C. He also mentions a point that web developers would do good to take to heart - the bottlenecks usually aren't in the code - it's dealing with external resources that's the problem...