Python code doesn't typically use the get and set methods so common in PHP. Normally, when writing PHP code, you carefully protect your instance variables by making them private, so callers can only interact with them via getter and setter methods. [...] Python's solution to this problem is more readable, it has a construct called a "property".

He compares two blocks of code that do the same thing - set properties on the object with the PHP side doing a bit more error checking (seemingly) than the Python side. They both apply a title property to a book object.

The problem. The PHP implementation [of the IP2C library] is a lot slower. Embarrassingly slower. Without any caching the Java version is able to do ~6000 queries per second. The PHP counterpart can push through ~850 queries. The implementations are the same. The stats provided by the author of the library are 8000 vs 1200. So about the same as my measurements.

He details the script, showing what parts the script is taking up the most time on. A large part of the execution is tied up in IO and the fseek/fread and readShort/readInt functions take up a good chunk.

He even tries removing the functions and making things a bit more streamlined. This helps, but still lags behind its Java brother. Check out the post for more statistics comparing the two.

When it comes to ORMs, it's all a matter of preference. Is it, really? This post compares side-by-side the code required to perform some simple operations with three OO database requesting API. The purpose is to demonstrate that productivity, and not only style, can vary a lot depending on the ORM you choose.

He's worked up a long list of examples including methods to:

• Retrieving an article by its primary key
• Retrieving the latest 5 articles
• Retrieving articles based on a complex AND/OR clause
• Retrieving articles authored by people of a certain group
• Retrieving an article and its category by the article primary key
• Retrieving articles and hydrating their author object and the author group

Each one comes with their own (usually simple) code. His conclusions point out different "bests" of each - like sfPropelFinder being the "most magic" and that some of the limits of Propel are very frustrating.

It's hard to choose which one to use without trying them out. As usually, there are more options - home grown custom programming or even building your own CMS (which I was once stupid enough to do). Programming from scratch is always fun and beneficial for your skills, however, if you need things up and running in no time or you don't do (or don't want to do) any programming, using a CMS is the way to go.

His vote is for Drupal but he's included a long list of specs comparing the features of both so you can decide for yourself on which is the better fit.

I've seen a lot of people talking about mysql_real_escape_string() vs addslashes() vs addcslashes(). There seems to be a lot of real confusion about what these functions do (even with the php.net manual around), especially when it comes to character sets. [...] So, I've decided to lay it all out in a few charts so there is no confusion about what each function does and how each can help protect against SQL injection attacks.

He ran some tests based on what the function does to see if it helps with certain things like "escapes with single quotes instead of backslash" and "prevents multi-byte attacks". He compares the speed and testability of the functions as well as provides a multi-byte breakdown oh how the mysql_real_escape_string function works with different character sets.

See, this job is importing data from a huge XML file into MySQL. After it is done, we want to compare the data we just added/updated to the data in the table so we can deactivate any data we did not update. [...] We then compared the two arrays by looping one array and using in_array() to check if the value was in the second array. [...] So, that was running for hours with about 400k items. Our data did not contain the value as the key, but it could as the value was unique.

He method, replacing the in_array call that had to do a full array scan for each time through the loop with an isset/unset combo on the unique key, changed the execution time down from about 4 hours to 0.8 seconds.

The benchmark suite covers all the usual bases, taking a simple task - like iterating over an array - and speed testing almost every possible way to achieve it. Most importantly, however, Chris takes raw numbers out of the spotlight and instead focuses on how the options compare with each other.

Since the results are generated live, they'll change a little bit each time the page is loaded. Each also includes a link to the code behind the benchmark so you can test it on your own system easily.

With PHP as module after some time the memory usage of Apache is growing and growing up to ~800M.
With mod_fcgid is stays on a steady ~100M
PHP configuration: only with the extension php_mysql.dll and eaccelerator.dll

A graph of the statistics is also provided.

While reading yet another article on why PHP Sucks (today's witty twist, "but It Doesn't Matter") I realized yet another reason that I'm glad to be programming in Ruby.

He sees Ruby as a "big open playground" and languages like PHP as big industrial factories that are more efficient for some things but can also "suck the creativity and life out of the people working in them". He compares a simple bit of Ruby code to PHP code that do essentially the same ask asks why you'd want to do one over the other.

There's plenty of comments supporting things both ways ranging from "that's a bad example" to "I think PHP is more of a playground - a disorganized mess".

Feature-for-feature, Eclipse and NetBeans are well matched. In fact, because they are both extensible, any feature gaps between the two can be filled in with third-party plug-ins. Eclipse and Netbeans are rapidly approaching the capabilities of commercial offerings. Most developers won't need more than what these two excellent development platforms provide.

A (very) brief list of the features of the two is also included, their similarities including SVN support and syntax checking.