Walter

Unfortunately, once again we're in complete disagreement. Every time we've debated, you've failed to convince me of anything and I've never been able to convince you of anything. So let's agree not to waste any more of each others' time.

Your example is ludicrous. 100,000 records with nothing in them is not realistic in the least.

However, if a single line of code can be 5% faster or 30% faster by applying simple rules the customer will gladly take it. I've asked every customer and every user I've ever encountered.

I regularly see a single query that takes 11 minutes being reduced to sub 1 second simply by applying my "standards". It takes me similar time to write unoptimized code as it takes to write optimized code. It only takes me a few minutes to change existing systems to get such benefits. You can't convince me to deliberately write unoptimized code.

Thanks


>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,