EFFICIENCY AND DEBUGGING
In this final section, I will touch upon some issues of efficiency and debugging, which are more art than science. Efficiency should not be your first concern when writing code You must first write code that works, and hopefully your second concern is keeping the code maintainable. As I write this, the Zend optimizer has become available. An optimizer can reduce memory use and execution time for you behind the scenes, but it can't address all issues of efficiency.
You will pick up some tactical design issues as you gain more experience in programming. These begin to gel as idioms—repeated structures applied to similar problems. Individuals and organizations tend to develop their own idioms, and you will notice them in code found in magazine articles and code repositories. Once you accept an idiom as your own, you can consider it a solved problem. This consistency saves time when writing code and when reading it later.
In most projects, a tiny minority of code is responsible for most of the execution time. Consequently, it pays to measure first and optimize the slowest section. If performance increases to acceptable levels, stop optimizing.
When a bug appears in your script, the time you spent writing meaningful comments and indenting will pay off. Sometimes just reading over troublesome code will reveal its flaws. Most of the time you will print incremental values of variables to understand the problem.
Measuring Performance
Three factors affect the time it takes to go from clicking on a link to seeing a completed Web page. First is the network. Your request must travel from the browser to the server, and the Web page must travel back to your browser. This will vary with location and the speed of connection. Second is the time it takes for a browser to display a Web page, once it has the HTML. Neither of these things is a function of PHP itself. Furthermore, they are largely outside of our control. We can try to keep the size of the HTML document small, and we can avoid complex HTML like nested tables, but we can't upgrade everyone's 28.8 modem. What we can control is the time it takes to assemble an HTML document with a PHP script.
The best way to measure how long a script runs is to print the time in important points in your script. Because most scripts take less than a second to run, you must use the microtime function. If you place the output in HTML comments, the display of the page will not be disturbed. Of course, the print statement itself will take some time. You can minimize this by simply printing the output of microtime instead of trying to convert its output into an integer. You can do the math later by hand or in a spreadsheet.
This is a contrived example of a script that performs complex math, then writes to a file. The first HTML comment contains the time on the clock when the script begins. That's followed by time when the 10,000 cosine calculations have finished. Finally we see the time when the 10,000 lines are written to a file.
Output of microtime
The microtime function returns two numbers. The first is a fraction of a second, the other the number of seconds since January 1, 1970. Notice that from the first comment to the next, the number of seconds changed from 950996931 to 950996932. The fraction changed from 0.95462500 to 0.38373500. In total 0.42911 seconds elapsed. Doing the math for the second part shows it took 0.080332 seconds. If the performance of this script were not satisfactory, I'd first look into improving the first half. It takes five times longer to execute than the rest.
Measuring Script Performance
<?
print("n<!-- " . microtime() . " -->n");
//fake some long calculation
for($index = 0; $index 10000; $index++)
{
$value += (cos(time()%360));
}
print("n<!-- " . microtime() . " -->n");
//write to file
$fp = fopen("data.txt", "w");
for($index = 0; $index < 10000; $index++)
{
fputs($fp, "Testing performancen");
}
fclose($fp);
print("n<!-- " . microtime() . " -->n");
?>
|
List Of Topics 
PHP
Related Jobs