Article Discussion: Writing Clean and Efficient PHP Code

If you've ever had to go back to an application you wrote after an extended period of time, you already know the value of clean, well documented and efficient code. But how can you make your code better? Here are some tips that'll help you speed up and clean up your development cycle.


Read the full article here: Writing Clean and Efficient PHP Code

Overall, not a bad article and the section on string literals helped me improve my code a bit; I'm pretty used to C/Java conventions regarding string literals and use double quotes out of habit.

However, I'm sort of scratching my head with the following example regarding looping over db results:

$r = mysql_query('SELECT * FROM someTable LIMIT 1500');
//OPTION 1
for ($i = 0; $i < mysql_num_rows($r); $i++) {
print mysql_result($r, $i, 'ColA').mysql_result($r, $i, 'ColB');
}

// OPTION 2
while (($row = mysql_fetch_assoc($r)) !== false) {
print $row['ColA'].$row['ColB'];
}

The article states:
>As you may guess, "OPTION 1" runs significantly faster. It has lower memory and machine...

I use option2-like methods almost exclusively in my code and also in all my other db code (C++/Java/MS Access). Not only does it look cleaner to me, but all indicators point to it being FASTER than option1 for large sets of data.

From the PHP docs for mysql_result:
When working on large result sets, you should consider using one of the functions that fetch an entire row (specified below). As these functions return the contents of multiple cells in one function call, they're MUCH quicker than mysql_result(). Also, note that specifying a numeric offset for the field argument is much quicker than specifying a fieldname or tablename.fieldname argument.


I did some simple benchmarking and my results reflected the PHP docs:

1. In cases where 1 row was returned and using only 1 column, mysql_result (option1) was faster by a smidge.
2. In cases where many rows (1500 as in the example), mysql_fetch_row (option2) was about 15% faster when only using 1 column from the row.
3. In cases where many rows were returned and 2 columns were used, mysql_fetch_row was on the order of 100% faster.

You are correct - I'm not sure how I overlooked that when I profread but I intended to say 'Despite what you may guess, "OPTION 2" runs significantly faster' when i said 'As you may guess, "OPTION 1" runs significantly faster'.

The part about the iterator was intended to lead the reader along the path you would take when trying to reason out which would be faster, but then point out that it isn't correct =)

I'll make sure it gets corrected; thanks for pointing it out! I feel like a moron for missing that =D.
BTW, for fastest results you can use fetch_row (w/o specifying it to be an associative) and it will be even faster using subscripts only rather than keys, but it relies heavily on you knowing what values are in what positions in the array, which can be a pain for debugging.

I think "even faster" is misleading. mysql_fetch_assoc:

It is significant with huge data sets =)

Fixed

If we are talking optimization, then you should remove any unnecessary function calls from the loop (i.e. mysql_num_rows($r)).

Instead of:

for ($i = 0; $i < mysql_num_rows($r); $i++) {

It should be:

for ($i = 0, $c=mysql_num_rows($r); $i < $c; $i++) {

pbwebguy, good catch =)

Nice article. I learned some new information.

I have a suggestion for Part 2: "Function development in PHP". The article could describe rules of creating fuctions. TNX!

I'm quite surprised that this article actually made it past the editor (is there one at all?). I haven't read many of the articles here at DevShed, but I hope this one doesn't represent the general quality.

The article should be about writing clean and efficient code, yet it mostly deals with efficiency. And it's dealings with this subject are poor at best. There is not a single piece of datum supporting the author's claims. And the tips presented are completrely irrelevant. Does the author know about the 80/20 rule? Has he ever heard the word "profiler"? Has he read even the most basic introduction to performance tuning?

The single vs. double quote example says it all. Maybe there is a difference. It's quite possible. But does it matter? NO! Trust me, you will have to search for a long time to find a PHP application where echoing stuff to the browser takes up a significant amount of time. And this was under the header "Best practices"!

It seems to as if the author really doesn't think about what he is claiming. He's just writing things that sound good. To quote from the conclusion: "How clean your code is can be determined by measuring the efficiency and maintainability of the application code"... Sure. So how *does* one measure the maintainability of code? And I'm not very convinced that the author knows how to measure efficiency.

Oh, and C++ doesn't have "wretched garbage collection". C++ has no garbage collection.

Then again, this article gives added credibility to the claim I once heard that writers of books about programming are people who weren't clever enough to make it as programmers

andnaess, pretty harsh =)

after i read the article on the site i really was not happy at all with it... i didn't collect my thoughts at all before writing it and it shows. i'm a newbie at writing so what i intend to say may not come out as well in the article as it does in my head when i'm thinking things through =)

your points are fair but there's not any need to get nasty in the future i'll follow my gut and just not allow articles i'm not happy with to be posted.