>>Easy enogh to fix: just run the code at the bottom of the post. I set iterations to 100000 to make sure that timing resolution is not a relevant factor
>>(take a coffee break after starting), but the trend can be seen at 10000 iterations clearly and at 1000 iterations only the afield()-approaches register.
>>Performance of afields drops as field count increases.
>>On test machines here (not too shabby but not top of the line) the afield()-apporach takes
>>at 20 fields about 012 times the time for udf(field())
>>at 20 fields about 035 times the time for #define field()
>>at 80 fields about 040 times the time for udf(field())
>>at 80 fields about 100 times the time for #define field()
>
>First, you are comparing apples to oranges. You function does not duplicate mine.

First, have you looked at the thread title ? If the *theme* is water-skiing and you show up wearing fins, who is the odd man? First you claim that you can water-ski wearing just your fins nearly as fast as everybody else with true water-ski on their feet ("I doubt your numbers"). When proven wrong, it is the fault of testing fins in a waterski-test, as they can be used for swimming / diving as well. Of course.

If you STILL not get it: the thread was about the search for finding a reasonable/best solution for "Detecting field presence in dbf", which the examples accomplished.

Mike already has pointed out, that doing multiple things with one function is not considered best practice and should be used only if other circumstances make it *necessary*. But you seem to have other ideas here as well.

At last, even your original comments did not reflect what you function really can return as possible result values. But at least my test on >0 was accurate for the thread topic.

>Second, as you seem to ignore, The amount of time is inconsequential.
This depends on your environment. I have datacrunching apps where a sizable part is called nearly a hundred million times, with system-near calls happening much more often. If I use your code just ONCE there, the app will run about 4 hours longer, as 10**8 calls are made using your code. On user side interaction, I strive for latency of less than 100ms between major page changes. Even on current low end machines every 6 calls can take away 1 ms= 1% of the time I have to do housekeeping.

>You seem to be hung up on speed and that's one of the things that is normally down on the list below more important programming considerations. Not that it should be ignored, but perhaps you are fixating on it.

Again, depends on circumstances. If your app is used by more than a couple of thousand people, splurging with your users time is inconsiderate and costly if those minutes are added up. Fixating ? Perhaps, but it is a small corner I have a knack for and sometimes get paid well to fix other peoples messes.

thomas