>So, if you've got a large number of iterations and/or method calls it could make a difference, but in normal usage it probably isn't worth worrying about. Like everything, you need to test it in your app to make a final decision.
>
>Interesting stuff... and Thanks!

It is interesting. It might be a good practice to optimize even for small tasks. It's an acquired methodology. It would be difficult to turn it on just for big projects if our practices did not have a foundation in the little tasks.

The first time I really noticed the clock (486D) was with a DOS dBase benchmarker I experimented with. It was a loop that set a variable to true if the loop counter was an "even" number, and false when it was an "odd' number. I think it was something like this:

* this loop took twice as long
for c=1 to 64000
lleven=.f.
if mod(c,2)=0
   lleven=.t.
endif
endfor 

* ... as this one
for c=1 to 64000
if mod(c,2)=0
   lleven=.t.
else
   lleven=.f.
endif
endfor

* ... and ever since, even for really simple logic routers I still code it
if 1+1=2
   * do something
else
    * do nothing
endif

Then, one evening I was at a FUG meeting and Marcus and Crew (it's good to live in Houston - sometimes) were presenting - and what d'ya know - the marquee geeks (at least those from Marcus's shop) included an unused "else" in their logic constructs.

Software development is always about the details. A project should always "strive" to perform like a Ferari even if the developer is only building a shopping cart!

Thanks for the "test" Paul!