>>>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.
>
>There's no excuse for writing slow code.
>
>Fastest possible? You'd have to reassess your techniques every time a version of the OS (well, not really OS, but of windowses) changes, to see if all the system level things perform at the same speed or perhaps some of them is now faster or slower than before, or can be replaced with a faster one. Then you'd have to recheck all your code whenever someone posts a speedup here. Eventually you'd get to the point where most of your code is running as fast as possible and fails because of all the things it does not do - things you should have written while you were speeding up the existing code.
>
>One should code for reliability and correctness first (i.e. the code should do what it should do), then for speed. Speed should also be measured in everyone's time: if my two hours of work will save the users at least ten hours a year, it's worth it. If I'd have to work two days to save them five seconds a year, it's not. I did have to work a couple of decades to be able to make an educated guess between the two, though.

Also - I have seen many situations where clients are unhappy with performance but the programmers are unable or unwilling to improve things.

This is all beside the point of my question - how can I dynamically - at compile time - replace a UDF with a native approach.