>Hi Mike,
>
>for sure we don't go about opening databases when they are already open. In fact, we encapsulated that probably 10 years ago, out of general principle.
>
>That said, what really counts is what takes how much time when. For that we used the modified profiler, and for views, a couple of our own simple recording tools.If it take 500ms longer but runs a total of 10 times in a session, etc. We try (don't always succeed) to be pragmatic about where we spend our time, keeping in mind that better is often the enemy of good.

I disagree. Once you reach a certain skill level, there is no excuse for not writing the fastest running code possible.

>
>Hank
>
>>I just had occasion to change a small udf that did an unconditional OPEN DATABASE to this...
>>
>>IF DBUSED("DATABASENAME")
>> IF SET("DATABASE")#""DATABASENAME"
>> SET DATABASE TO DATABASENAME
>> ENDIF
>>ENDIF
>>
>>and guess what - the app starts visibly faster and things seem snappier overall. Maybe most programmers and most clients don't care about snappy, but I do. dbused is over 600 times faster than open database. I'll gladly take that.
>>
>>>1000's of times at one time, or 1000's of times distributed over a month/week/day/hour?
>>>
>>>The .1ms difference (it's less) of executing 4 lines of prg rather than 1 line of inline code will make no appreciable difference to a form appearing, or a report being ready, if it's called 1 or even 10 times during that process. If it's called 1000's of times in preparing a report, it could make a difference of a second or two, probably. If it's being called 1000's of times in bringing up a form or preparing a single report, I would look at why, and refactor the why.
>>>
>>>Additionally: 60% of software development cost in in maintenance, not development. Wrapping common functions to accommodate new options insulates the application in that changes can be made in one place, and apply everywhere. Given the low processing cost for doing so, and the benefits of doing so, I most generally do just that. It has saved our collective rear-facing protuberances on more than one occasion.
>>>
>>>Hank
>>>
>>>>>>Hey all
>>>>>>
>>>>>>I've got a UDF that is something like a cross between SEEK and LOOKUP(). The problem is - calling a UDF is slower than native functions.
>>>>>>
>>>>>>The function is liberally scattered everywhere. The parameters do not match the LOOKUP function, which would have been virtually perfect. I know a search and replace might work, but that will break a lot of code too.
>>>>>>
>>>>>>So - an idea has been tickling around my mind,
>>>>>>
>>>>>>Given the existing call ... MYSEEK(seekthis,"inalias","thistag","returnthis")
>>>>>>
>>>>>>would it be possible to #DEFINE and make the above into something native at compile time?
>>>>>>
>>>>>>Thanks
>>>>>Hi Mike,
>>>>>
>>>>>the cost of a call to a wrapper function is negligible, unless you are calling it thousands of times, which you shouldn't be doing anyway. So rewrite myseek to use LOOKUP() where appropriate, and you're done.
>>>>>
>>>>>Hank
>>>>
>>>>We are calling it many thousands of times because of it being used in queries. I disagree with the whole "premature optimization" schtick. Not optimizing at every chance is the true root of all evils.