THE VIEW -- Speed Up Your LotusScript Loops with the Custom statusBuffer Class

How much does it cost to print those on-screen messages that tell your users the status of a processing job? The common practice of printing a message on the status bar like the one below is almost a necessity when processing a large number of documents or when undertaking a slow process, but the cost can be quite high.

In “The Most Efficient LotusScript Loop Constructs for High-Performance Document Processing” (THE VIEW, May/June 2006), I presented a performance-testing methodology and discussed the various tests I ran to determine the most efficient loop constructs. One of the tests looped through 50,000 documents in a view and incremented a variable to keep a count of the total number of documents processed. I performed the test twice. In the first test, the code simply looped through the documents and accumulated the total (Figure 2). For the second test, I added an extra line of code to print the total to the status bar each time that it was incremented. (Figure 3).

Figure 2 Code that loops through the documents in a view and increments a counter variable


Set docResult = viewResults.GetFirstDocument		
While Not (docResult Is Nothing)	
    longTotal = longTotal + docResult.Result(0)	
    Set docResult = viewResults.GetNextDocument( docResult )
Wend

Figure 3 Code that loops through the documents in a view, increments a counter variable, and

prints the counter to the Notes status bar for each increment


Set docResult = viewResults.GetFirstDocument		
While Not (docResult Is Nothing)	
    Print "1"	
    longTotal = longTotal + docResult.Result(0)	
    Set docResult = viewResults.GetNextDocument( docResult )
Wend

The results were quite surprising: There was a large difference between the time it took to process each loop. The first loop took 8,420.1 seconds and the second loop took 42,431.4 seconds. As I wrote then, “The results show that the print statement introduces a significant overhead to the agent execution time — in this case, an overhead of over 500%. Obviously, this percentage would be smaller if the loop were performing more tasks than simply totaling a value; however, the results indicate that the overhead of using the print statement could significantly slow performance.”

Thus, from a performance point of view, it seems like a bad idea to use the print statement to update the status bar. Nonetheless, it is fairly important to let your end-user know that a process is still working and actually making progress. Otherwise, the user might think that your code has crashed or otherwise stopped working. So, how can you update the status bar and keep the end-user informed, without adding a significant overhead to the processing time?

The solution is to update the status bar periodically. For example, you may decide to update the status bar only every 25th time through the loop. That way, you can have the best of both worlds — keeping the user informed of the progress but adding a smaller overhead to the overall processing time. I’ll show you how.