Mike,

>>I know you're obsessed with these kind of optimizations, but what is optimized really depends on the population. For only two records having an index lookup really means LESS performance compared to a table scan.

>Obsessed has a bad connotation. You seem to be obsessed with arguing these points. I used the word optimal because the change I suggest is the best way I can see to do it.

I have a problem with folks giving just these kind of advise to 'optimize' their code. It is just because it does not solve any performance problem at all. Your knit-picking milli seconds here in a problem that is talking about multi-seconds performance problems.

>Index or not LOCATE FOR UPPER(FIELD) = variable will be better than LOCATE FOR UPPER(FIELD) = UPPER(VARIABLE) and certainly better than UPPER(OBJECT.PROPERTY). I did say "even if you have no indexes". If the table gets larger, he could always add the index later. That is certainly better than going back to change code, which requires potentially huge re-testing. It takes no more time to do it like that. I suggested the optimal way for this situation.

Let's look at this more closely. Take the following program.

CREATE CURSOR Test (Charfield C(30), IntField I)
** INDEX ON charfield TAG charfield

FOR nT = 1 TO 100000
	APPEND BLANK
ENDFOR

cMyVar = "Test"

nSec = SECONDS()
FOR nT = 1 TO 10
	LOCATE FOR CharField = cMyVar 
ENDFOR
? SECONDS() - nSec

nSec = SECONDS()
FOR nT = 1 TO 10
	LOCATE FOR CharField = ALLTRIM(UPPER(cMyVar)) 
ENDFOR
? SECONDS() - nSec

SELECT MyNetworkTable       && with 100.000 records.

nSec = SECONDS()
FOR nT = 1 TO 3
	LOCATE FOR lbd_cycleno = ALLTRIM(UPPER(cMyVar)) NOOP
ENDFOR
? SECONDS() - nSec

nSec = SECONDS()
FOR nT = 1 TO 3
	LOCATE FOR lbd_cycleno = cMyVar NOOP
ENDFOR
? SECONDS() - nSec

Worst case scenario: In the example above I create a 100.000 record cursor and try to locate a non-existing value in it. With the (A) LOCATE FOR CharField = cMyVar, it took .641 for 10 iterations (1 million records processed), with the (B) LOCATE FOR CharField = ALLTRIM(UPPER(cMyVar)), it took .828 second, so about 1.29 times (29%) slower.

I'm not impressed. Not only because performance problems generally present themselves in hundreds of percentages in stead of tents, but also because this is the worst scenario.

The second part of the test takes a table from my local 100Mbs network. Results, (A), 21.672 seconds, (B) 21.781 seconds. A difference of 0.5% !!! Of course any client is going to notice this performance difference .... LOL ....

Now uncomment the INDEX ON command (I removed the NOOP commands in the second part of the test for rushmore kicking in) and run the test again. Result: both (A) and (B) performed at the same speed: No noticable performance difference.

Conclusion: These kind of performance tuning tips should go where they belong: IN THE TRASH BIN. It shows lack of understanding performance problems in general. Performance problems almost always have to do with optimizing disk or network I/O, Concurrency, Memory consumption, and only on the last part it has to do with CPU resources. Unless people do understand this any attempt to solve performance problems is going to be hard and painfull.


>It it better to avoid performance problems by not creating them in the first place.

>>Programming from a performance pov is only neccesary if you expect that piece of software to be susceptible to performance problems. Otherwise don't bother, your time is not worth it.

>No customer I've ever met agrees with you. They want the best software and they actually believe that is what we will give them.

You did not even ask your clients :) Seriously, if a customer asks for a car to drive from a to b, I'll will build him a car, not a formula 1 car .... There is a big difference between the best performing application and the best application. Otherwise I would have written my whole application in assembly. Our job is to create satisfying products that meet our clients expectations AND NOTHING MORE THAN THAT.

Walter,