>Hi Mike,
>
>I agree with you what we should always try to find the best and fastest algorithm.
>
>On the other hand, it's quite often the situation - if it's ain't broken, don't fix it. There should be a balance found when changes are absolutely necessary and when 1ms speed gain would not benefit in the whole picture.

No kidding. "If it ain't broken, don't fix" means that humanity would still live in mud huts. They worked fine, supposedly for thousands of years. Don't let that saying stifle progress.

If a program uses TYPE everywhere, instead of a UDF there is no way to make the improvement without examining / changing every instance of TYPE. Is it checking for the existance of a field or a memvar? We can't use search and replace to change them all as a result of having to determine that.

>
>>Thomas
>>
>>As I've tried to say in the past. If one app uses only the fastest techniques, it will be demonstrably faster than another app. I expect frameworks to assist with this.
>>
>>That requires collection of the fastest techniques. Some don't see the point. Milliseconds here and there don't matter much on their own, but that is a limited perspective. I'm not "over-emphasizing" speed - another limited perspective. I want more speed because I want to use a UDF because I want better maintainability and better reliability. The use of the UDF causes a drop in speed relative to the use of a direct test such as TYPE() or even AFIELDS().
>>
>>I did something with MaxFrame that I'm sure has not yet been incorporated, though I submitted it long ago. VMP has a project hook that adds and/or removes lines from a procedure in the main.prg. These lines help the project manager find components, allowing the project to be rebuilt quickly if damaged. These lines were/are processed with STRTOFILE and lots of conditional code.
>>
>>I redid that code by pulling the file into a cursor and using replaces etc. The update is obviously and visually faster, not just by timings. Without an interest in finding the faster technique this has been left in and deemed "acceptable" by the others using it.
>>
>>This attitude hurts my productivity which hurts my customers indirectly. It makes me wonder what little bits of slow code everywhere is doing to humanity. Just try to add/remove a program in Windows XP to see how a poor design has allowed slowness to creep right out in front of the user's noses!
>>
>>I'm already satisfied we have found the best technique.
>>
>>Thanks