Showing posts with label Simple Optimizing Tips for PHP. Show all posts
Showing posts with label Simple Optimizing Tips for PHP. Show all posts

Monday, January 11, 2010

Simple Optimizing Tips for PHP Part IV - By Example (Part I)

Ss we write PHP code (or any language for that matter) we begin to start thinking about optimizing code. But even though our intentions are for "the greater good", we sometimes miss things that should be obvious.

Today's article takes a look at:

By Example


All developers progress at their own rate. As we progress, a few things that become evident is the existence of built-in php functions that can replace many of our own custom code, simply because we didn't know any other way. We also learn how to see repetition in our code and how to simplify it, when we should separate functionality into their own functions (or even classes!), and also just *know* when something will or will not work from personal experience. During this phase in life, we're becoming a senior developer.

Before we get to this point though, we are intermediate developers. Intermediate developers (in my honest opinion) is where a LOT of innovation comes from. It's from this level of developer that they are exploring PHP's full potential and how to exploit it to their benefit. When we are reaching the end of intermediate level and are looking to become the senior level developer on our team, we begin to try to search for ways to better ourselves as a developer. Unfortunately, such tutorials are very scarce and hard to find.

This tutorial is not to be the end-all be-all, but it is intended to help an intermediate find that next level. And we do this by examples.

Since even simple examples can lead to a book's worth of information, I plan to break this 4th part of Simple Optimizing Tips for PHP into sub parts. This will help reduce the amount of time it takes you to read this article, but also not try to slam too much information into your brain. Please keep in mind that while some of these examples won't exactly speed php's performance up, they will instead inadvertently teach you new methods and in turn try to warp your mind into a more sophisticated developer.

So without further ado, let's begin!

Our first example is the following function:


function multi_array_search($search_value, $the_array)
{
if (is_array($the_array))
{
foreach ($the_array as $key => $value)
{
$result = multi_array_search($search_value, $value);
if (is_array($result))
{
$return = $result;
array_unshift($return, $key);
return $return;
}
elseif ($result == true)
{
$return[] = $key;
return $return;
}
}
return false;
}
else
{
if ($search_value == $the_array)
{
return true;
}
else return false;
}
}


This function is perfectly valid, and works exactly as intended. However, there are a few things that one should notice right away:
1) The spacing and tabing of the data is not lined up nor consistant, making it hard to read.

2) The function is not taking advantage of the typehints that are now available in php 5.

3) Some of the code is a bit long and can be reduced to smaller lines without obfuscating the code.

4) The naming of some of the variables could be redefined to make understanding their purpose easier.

4) There exists absolutely no commenting in this function to explain it's purpose.

5) The possible return value is either boolean (true AND false) OR array!

6) The 2 parts of this function (the first if and the following else statements) could be refactored to make more sense and be more useful.

So now that we know this, how can we make this function better? Here is a revised, optomized solution.

/**
* @author John Doe
*
* Takes an array and searching for a value within.
*
* @param string $search_value
* @param array $search_array
* @return boolean // Returns true if a search value found, false if not.
*/
function multi_array_search($search_value, array $search_array) {
$search_result = false;
foreach($search_array as $key => $value) {
if(is_array($value)) {
# We have an array, so let's recursively search the subarray values
$search_result = multi_array_search($search_value, array_unshift($value));
} else {
# We have a string, so let's compare and see if we have a match
if($value == $search_value) return true;
}
}
return $search_result;
}


Notice that we are using the recursive method that was explained in my second tutorial on recursively looping through arrays. Also, we are now only returning a boolean value from this point on. In the case that we find a value, we return only a true, otherwise (and by default) we return false.

Now the above may or may not run faster (I haven't exactly run a test on this), but it is more simple, less code, and more understandable with comments that guide the way.

For the second part of By Example, we will be looking at redundant functionality and definitions, and learn how to better adjust our code to be more useful rather than bloated.

Friday, December 11, 2009

Simple Optimizing Tips for PHP Part III - Commenting

As we write PHP code (or any language for that matter) we begin to start thinking about optimizing code. But even though our intentions are for "the greater good", we sometimes miss things that should be obvious.

Today's article takes a look at:

Commenting

Commenting, to some, doesn't make sense to be an "optimizing" tip. I'm here to tell you that this is wrong. Commenting is, without a doubt, a key part to optimizing your code!

If we consider all the scripts we have built over the years, one of the fundamental things that allow a script to be a "strong" and "well written" script is its commenting structure.

Comments allow developers to find key methods and components that make a script operate much easier. Comments also allow for maintaining code and, in the process, make debugging these scripts easier. Thus it optimizes not only PHP, but also YOU!

There are 3 supported methods of commenting blocks in PHP. They are:

// (2 forward slashes) - This commenting break comments out one line.

# (or hash) - This commenting break also comments out one line.

The only difference is this method was (and still is) used in Unix

programming.


/* */ - This commenting style is for one to many lines of code.



While knowing the commenting blocks is all good and great, there exists 3 main questions that are asked by all levels of developers:
1) Where should I comment?

2) How often should I comment?

3) What kind of commenting style should I use?

Where should I comment?
This is perhaps the trickest question of all. The key here is if we define where to make comments, we could inadverdently convince a developer to make comments more often then he should. So to answer this quesiton without misleading and causing more harm than good, I have a few examples of "where" one should comment.

You should comment on functions, variables, or complex blocks of code in which:
a) the meaning of the definition is unclear,
b) where it wasn't written in the most optimal way,
c) where it was a "hack",
d) where an "important" piece that solves a complex issue,
e) where a "change" from a privious method existed,
f) when commenting "out" an old method,
g) when setting ground rules for said definitions.

Since there are obviously a lot of instances commenting is great, we must be careful not to over do our comments. Which leads us to the next question...



How often should I comment?
You should not comment too heavily, and you should not comment too lightly. An even medium is suggested, with an influence on the lighter side.

While some will say lots of comments help people understand things, I will disagree and say it causes more complexity than is needed. If we end up having 100 lines of a 300 line file being code, and the other 200 lines of code being comments and whitespace, it very evident that the code is either written so poorly that lots of comments are needed to explain how it works, or that the author himself is not sure how the code works.

Whlie some will say this is not true that they just "like" to make long, elaquent comments, I can respond with that there is a time and place (such as a wiki) for such long-winded explanations.

So, how do we solve this issue of not writing too much, or too little comments?

It's very simple. As stated in the "Where to comment" above, you should mainly be commenting on pieces of code that are not very easy to follow. So, to explain these pieces, here are a few scenarios that should help you on your way:

1) Imagine that you have a variable that has been defined by an included file. A comment where the variable first appears would be an extremely helpful spot to point a new developer (or even your future self!) in the right direction.

2) Say we have a new class or function that we have writte to save ourselves some time. Make a comment explaining the purpose of this class/function!

3) Imagine that you have a few included files that perform other operations that will make the script you're currently viewing operate correctly. You could make 1 comment for all these includes, explaining why they are there and what purpose they have.

4) One day you have to debug a piece of code but you forgot how it works. So you start back-tracking through the code and figure out, piece by piece, everything that was needed to make the end result work. Find the most vital part of your code, and create a comment there explaining just what you found! There may be a workound later.

Whlie these examples are small, the concept should be quite clear. Try to consolidate your comments, but try to keep them short and sweet and to the point! The comments are there to leave breadcrumb trails and help debug, NOT to create a new bestseller book!

What kind of commenting style should I use?
The commenting style I will suggest here is using phpDoc commenting format. To learn about phpDoc, I would recommend their website for more information.

Why phpDoc? Because, for me and the teams I've worked with, the style is clean, organized, and even supported in IDE's such as Zend and Eclipse!

While I know this article was very short, I must break here. A whole book could be focused on the issue of commenting methods (and books DO exist on the subject!), but today just isn't the time for that sort of article. For now, have a merry christmas!

Be sure to check out my next optimizing tutorial : By Example

Monday, November 16, 2009

Simple Optimizing Tips for PHP Part II - Recursive Functions

As we write PHP code (or any language for that matter) we begin to start thinking about optimizing code. But even though our intentions are for "the greater good", we sometimes miss things that should be obvious.

Today's article takes a look at:

Recursive Functions

Functions are one of the most important tools we have for developing reusable, structured code. When we build our functions, we are mainly looking at ways to reduce redundancy and create effective ways to perform the same operations we use in either 1 script or all our scripts.

In our attempts to reduce redundancy, we inadvertently create more redundancy or miss opportunities to simplify how our code executes.

Consider this situation. We have a multidimensional array set that we want to display not only in a div, but also divs inside of divs. One method we could solve this with involves something like the following code:


$array = array("info" => array("employees" => array("name" => array(array("first" => "John",
"last" => "Doe",
),
array("first" => "Bob",
"last" => "Henry",
),
),
),
"departs" => array("building_1" => array("Sales",
"PR",
"HR",
),
"building_2" => array("Developers",
"Management",
),
),
),
"misc" => "Created in 2009",
);

function display_information(array $data_array) {
foreach($data_array as $key => $value) { // info
if(is_array($value)) {
foreach($value as $sub_key => $sub_value) {
if(is_array($sub_value)) {
foreach($sub_value as $sub_key2 => $sub_value2) {
if(is_array($sub_value2)) {
foreach($sub_value2 as $sub_key3 => $sub_value3) {
if(is_array($sub_value3)) {
foreach($sub_value3 as $sub_key4 => $sub_value4) {
echo "$sub_key4 => $sub_value4";
}
} else {
echo "$sub_key3 => $sub_value3";
}
}
} else {
echo "$sub_key2 => $sub_value2";
}
}
} else {
echo "$sub_key => $sub_value";
}
}
} else {
echo "$array_val";
}
}
}
While the above code works exactly as we need it to, it isn't exactly written the most efficient or optimized way. If you look at the code above, you can already start to see the redundancy involved with it. It's the exact same foreach statement whenever our condition of "is_array" rings true, and the exact same statement when it rings false. Plus, since we have to keep track of where we are in each of our loops, we get to the point to where our foreach loop parameters are extremely difficult to keep track of and the code in general is just a mess.

So how can we optimize the code above to be less redundant, and in return create a quicker, less line, and optimized solution? We do it by creating a recursive function.

A recursive function is just a method that calls itself from within itself. It helps reduce redundancy by applying similar logic to a result set without having to rewrite the exact same methods over and over again (as in the above code).


$array = array("info" => array("employees" => array("name" => array(array("first" => "John",
"last" => "Doe",
),
array("first" => "Bob",
"last" => "Henry",
),
),
),
"departs" => array("building_1" => array("Sales",
"PR",
"HR",
),
"building_2" => array("Developers",
"Management",
),
),
),
"misc" => "Created in 2009",
);

function display_information(array $data_array) {
foreach($data_array as $key => $value) { // info
if(is_array($value)) {
display_information($value);
} else {
echo "$array_val";
}
}
}


Nice isn't it? We take a 29 line function from our original example and turned it easily into a 9 line optimized function. This not only reduces the lines dedicated our function, but it also makes it easier to read, faster, and above all optimized!

Recursive functions can be used in many instances. The key for the developer is to recognize when it's needed by carefully examining the code and determine if it's needed. This example (while a bit exaggerated) will hopefully open your eyes and also teach you just one more simple thing you can do to create more optimized code for PHP!

Tune in next time for my next optimizing article on, Commenting.

Monday, November 9, 2009

Simple Optimizing Tips for PHP - Part I

As we write PHP code (or any language for that matter) we begin to start thinking about optimizing code. But even though our intentions are for "the greater good", we sometimes miss things that should be obvious. This article is one of many to come that hopes to point these things out to you, and in the process train your mind to think of quicker steps you may otherwise haven't really thought about.

Today's article takes a look at:

Loop Arrays
When we use loops, the goal is simple: iterate through an array set, and do something with the results. Most developers understand this quite well but they build the basic looping structure without considering how poor methods of iteration will affect their code's performance.

Example:

$sql = "SELECT * FROM `user`";
$rst = $dbh->fetch_rows($sql);

for($i = 0; $i < count($rst); $i++) {
// do something
}


For some, the problem is quite clear. For others, the code above seems quite valid and perfectly fine. However, the above can cause serious latency in your application(s) if you follow this type of constructing loops enough times.

The issue exists with the loop piece $i < count($rst);

Consider that the query we used returns 2000 records. While the for loop is completely valid, the issue exists in that, for each iteration, you are now counting the number of results ($rst) in each and every iteration!. This means that if we have 2000 records, it's going to get a count of our $rst array 2000 times!

What's worse is that when you issue the count() function on a big array, it must load this array into memory, check it, and then finally clear the tmp data. This in turn puts a small hamper on the server when done once, but when we are doing it 2000 consecutive times just for the sake of iteration, the overhead becomes very evident.

The solution for this is quite simple. You should first just get a count of the number of records, assign it to a value before the loop, and then use this for your iteration. For the PHP engine, is much faster to check a flat numeric value 2000 times rather than issue the count() sequence (explained above) 2000 times.


The Full Solution

$sql = "SELECT * from `user`";
$rst = $dbh->fetch_rows($sql);

$total_users = count($rst);
for($i = 0; $i < $total_users; $i++) {
// do something
}


Where the above will find some flack from experienced users is the situation where you may really need a count of an array. Such situations include: removing a key from an array, adding a new key to an array, popping values off an array, etc...

For these situations, the solution is not to use a for loop, but rather a foreach loop. Since a foreach loop iterates one array key at a time, we can remove/add array keys without the need to keep a count. Plus, if you really want to keep track of your $i variables count you can just assign $i before foreach loop and increment it within the foreach.

Example:

$sql = "SELECT * FROM `user`";
$rst = $dbh->fetch_rows($sql);

$i = 0;
foreach($rst as $key => $value) {
echo "|| $key => $value => $i || ";
$i++;
}


While the above can be optimized a hundred different ways, the point is that we should be taking into consideration how a script in PHP operates. Instead of just forcing it to carry out redundant operations and continue to put more overhead/waste of processor cycles on our server, why not try to optimize the code and make a cleaner, faster application?

Tune in next week for my next article: Recursive Functions.