IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     
 
developerWorks
AIX and UNIX
IBM Systems
Information Mgmt
Lotus
New to Lotus
Products
How to buy
Downloads
Live demos
Technical library
Training
Support
Forums & community
Events
Rational
Tivoli
WebSphere
Architecture
Autonomic computing
Java™ technology
Linux
Multicore acceleration
Open source
SOA and Web services
Web development
XML
About dW
Submit content
Feedback


developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

developerWorks
A collaboration with Domino developers about how to do it and how to get it right in Domino

Bob Balaban writes:

In LotusScript, instead of testing for a null string with:
if s = "" or s <> ""
It's much faster to do it this way:
if len(s) = 0

I have heard this often, and I was curious about the actual difference. So, I decided to test it out. Bottom line: I wouldn't bother.

The clock on a Windows PC only "ticks" every 100th of a second, so to get an accurate timing on something you have to do it a bunch of times. I like to wait until the timer "ticks over" and then start repeatedly doing whatever it is I'm timing, counting how many times I can do it in a pre-selected amount of time. Here's the subroutine I modify to do the test.

Function TimeControl(Byval limit As Single) As Single
     Dim startTime As Single, endTime As Single

     Dim iters As Long

' do your initialization for the test here

' ...

     startTime = Timer

     While startTime = Timer

             ' wait for the next timer tick

     Wend

     endTime = Timer + limit

     Do

             iters = iters + 1

' put the code you want to time here.

' ...

     Loop While Timer < endTime

     TimeControl = (Timer-startTime) / iters ' return time per iteration

End Function

We should get a pretty accurate measure provided limit is at least 4 (seconds) or so. If the task takes a lot longer than we expect and the final iteration goes past the limit, it uses the actual elapsed time to calculate the time per iteration.

Since the mechanics of looping and checking the timer takes a little time, I like to call this unmodified function as a control, and subtract the time it returns from the time for whatever I'm testing. So I might write:

Dim control As Single, tOpenDoc As Single
control = TimeControl(5.)

tOpenDoc = TimeOpenDoc(5.)-control

It's best to run the test several times, throw out high/low values and average the rest, to account for differences in how busy your system might be at the time the test is running. Using this technique, I timed 5 things:
Operation: Time (sec)
Test string with = when string is blank .00000058
Test string with = when string is not blank .00000058
Test string with Len(x) = 0 when string is blank .00000035
Test string with Len(x) = 0 when string is not blank .00000047
GetDocumentByID in a local database .00020882


Using Len is faster, but the difference is only about two ten-millionths of a second -- if doing five million string comparisons, you'd see a one-second difference in your code's execution time. Note that the constant "" is built-in to the LotusScript engine, so there is no question of allocating memory.

Most of the time in a typical script is spent opening databases and documents, reading and setting document field values, saving documents, navigating views and collections, and other such operations that take hundreds to millions of times as long as a string comparison. Given that, the amount of time you save by using Len is not noticeable, so it's better to maximize readability/maintainability. For me, the equal test is more readable. If you take the developer time you would spend changing every = "" to a test of Len, and apply that to eliminating unneeded database operations instead, you'll get way more bang for your performance-optimization buck.

Andre Guirard | 27 February 2008 02:56:00 AM ET | Home, Plymouth, MN, USA | Comments (3)

Lotus Software

Search this blog 

Disclaimer 

    About IBM Privacy Contact