Not all employers are equally enlightened and, for my sins in some former life, I sometimes have to code ASP pages using VBScript.

This company, realising that they had paid the supplier of an order processing system a small fortune for the privilege of beta testing the software, wanted to monitor the system's internal error files for themselves. The ASP application was to query an error log file created by the newly installed software. It ran on the company's intranet and the log file was in a MS SQL Server database.

The ASP application was straightforward enough, request a date, query the log file and display the entries for that date.

As you can see, some of the entries can be a bit verbose but it worked fine until one day when it took 15 seconds to produce any results. Repeated attempts at different times of the day always took about the same time so it was unlikely that it was down to server or network load. It should be noted that on this particular day there were 500 plus log entries

Ever the evangelist when it comes to PHP I decided to to rewrite the application as this seemed a good opportunity to prove its superior speed. I ran it on the same data (the day with 500 records) and it took 0.2 seconds.

Yes! A result - score 1 to PHP!

However, to me, a seventy-fold increase in performance looked too good, so before I pressed the case for PHP I thought it prudent to make sure I was comparing like with like and see why there was such a difference

First of all there was the connection to the database. The ASP program connected using ADODB so it wasn't an ODBC connection that was holding it back. PHP was using its mssql_xxxx library functions. All's fair so far.

The main difference was the way the output was being handled. Both programs had a DisplayOutput() function which queried the database and looped through the results. But there was a significant difference:

• the PHP version was echoing each record as it was read
• the ASP version concatenated the data into one long string then output the whole lot at the end

So, could this account for the difference in time? Well there was one way to find out - write an ASP version that output each record as it was read, and write a PHP version that returned a long string for output at the end. I put a microsecond timer functions into each of the four versions and printed the time taken at the end of each run. The average times for the four versions were Avg run times PHP ASP Short string output 0.206 0.778 Long string output 0.296 14.460 Time ratios PHP ASP Short string output 1.00 3.78 Long string output 1.44 70.19

There is no doubt from the timings that there was a significant degradation in performance when then the results were concatenated into one long string and then output at the end of the processing. It was particularly noticeable with ASP. Even with the PHP versions the run time was 44% longer when concatenating long strings.

So the lesson is: when you are dealing with large amounts of output, avoid code like this

function getResults() {
    $resultStr = "";
    while (fetch results from db) {
        $resultStr .= $the_output_text;
    }
    return $resultStr;
}

echo getResults();

function getResults() {

    while (fetch results from db) {
        echo $the_output_text;
    }
}

getResults();

And a final comment on ASP performance
As the table of run time ratios shows, the best ASP code took almost four times longer than the best PHP and was still significantly slower than the worst PHP time, taking 2.6 times as long to complete.

© B A Andrew 2004. All rights reserved.