If a solution can be put together quickly in PHP, then its the language of choice.

[...] also written about the silliness of predictions of PHP’s imminent downfall. PHP is not without its warts, but it also supports a vibrant ecosystem of frameworks (Zend [...]

First of all, multi-threading is used to perform one task while you are doing another concurrently in parallel, such as loading one section of your application while the user is viewing another. Or Pulling live data from a third party to update content within your application with no apparent delay to the end user. These are just a couple examples.

Ok, now lets look at the concept of a web site. A user loads up the home page of a website, then has several options (links) of what to do next. When the user clicks on a link, then another web page loads up… then the next. Bandwidth is a commodity just like anything else, and we don’t want to burn unnecessary bandwidth just because we can… so we don’t. Anyway, if we wanted to “thread” the rest of the pages, it would have to be a joint effort on the client and the server because if we just did it on the server, it would be of no use to the client. So we could virtually “thread” it with AJAX. I know, this is a major part of the debate, so bare with me.

Alright, for the pulling of live data, in order to do so with the server side scripting language, we would have to hold the page in limbo (a little loading bar at the bottom of the screen indefinitely) and continually push chunks of data to the client. As they are pushed to the client, they will be forced to the bottom of the document, so you will have to use JavaScript to force the chunks of data where they need to go. There is one problem with that though… the onload function never fires because we’re holding the page in limbo to compensate for the threading. Again, AJAX technology is clearly a better choice for updating third party data.

Now on to one of the main arguments of the document… multi-core processors/SMP servers. Yes, multi-core processors are cool, and yes it is true that PHP can’t take advantage of them by using multiple threads for various tasks while it is running… Or can they?

PHP scripts just sit there until a user tells it that it’s time to be interpreted. The Apache webserver runs under such a user that can tell the PHP scripts to be interpreted, and also tell them which core/processor to run on. Yes, the Apache web server supports SMP, so indirectly, PHP can take advantage of multi-core/SMP systems (How and why is beyond the scope of this comment).

Now to my last point. The author mentioned something about pulling database queries and then running other code in another thread to build a table or something. I see this as very trivial optimization, and I see the performance gain vs. time spent on programming it (not to mention the amount spent for the programmer) as being so minuscule that it wouldn’t be worth it.

Ok, so you would gain maybe a couple hundred extra pages per million (*assuming you programmed it correctly and your optimizations really worked), but if you really need the extra performance, then it means you are making money and could just throw a couple extra servers at it behind a load balancer using a couple databases utilizing replication. The amount speant on the extra servers… about 4 – 8 grand (depending on how beefy the servers are), and an extra 3 grand or so per year for bandwidth (assuming you need it).

Weigh that in with the hiring of a programmer who beats on his chest because he’s a master at programming in a multi-threaded JDK/Tomcat environment and requires Java Enterprise Edition to be efficient… up to 20k per year….. And, to top it off, you’re still going to need the few extra servers behind a load balancer and a couple of Oracle servers utilizing replication (12-18 grand).

So it boils down to this… 3k per year 8k investment… 20k per year 18k investment. I’ll take the 3k 8k every time.

* Multi-Threaded
1. Pull the query O(n) where n is the number of rows.
2. Build the table O(n)
3. Populate the table O(n) Assuming you have an efficient search and replace algorithm.

1 and 2 happen in parallel so we end up with
= 2 * O(n) (assuming an efficient search/replace algorithm)

* Sequential
1. Pull the query O(n) rows
2. Build the table at the same time as pulling the rows (Accounted for in the first O(n).

= 1 * O(n).

As we know from algorithms, the constant before the O can be omitted, so the run time is essentially the same, but as we can see, you save time from just building the row while you pull the data. Again, it’s a flawed point by the author (it was in a comment), even though I can see where it would be beneficial, just not in the case that he mentioned.

The way I see things is this: So what if something might be better or faster. Currently we’re not seeing bottlenecks in our software where we would need to go somewhere else to optimize the software. When that becomes a problem, it will be told to us that we need to either optimize our code, or look into something else to program. I dont see that happening anytime soon though.

A key problem with this guy’s thoughts is that Perl went away in favor of PHP. That only happened because web development using perl wasnt the best way to do things. PHP is meant for the web whereas perl is not. People used perl because we didnt have PHP ‘way back when’.

Things evolve. Who’s to say that PHP WONT be able to multithread?

I doubt PHP will ever ‘die’ unless zend decides to kill it off in favor of something else.

Ramble ramble ramble. Gotta get back to work