Re: More Questions on UDF

<snip>

Surely it won't be *that* bad. After all, the object resolution will
only
take place once; the first time the UDF (program) is called. After that,
it
should be almost as quick as a service program procedure call. Or is it
different when SQL is brought into the mix?

</snip>



Unless something has changed, yes it is that bad.



Just as experiment, write two programs that do nothing except say adds
one to variable.



1. One is a service program with a single procedure receives a few
parms.
2. A regular program that receives the some parms and leaves LR
off.



Now just write a couple of test programs. One that loops around and
makes say 100,000 calls in a tight loop to the procedure in the service
program.



In the second call the program in a tight loop.



Unless something has changed, you will note a few things.



1. The service program test will finish so quick that you will
hardly have time to lift you finger. You will probably have to increase
your loop number.
2. Your program test will run and run.
3. If you look at your system usage, you will see almost nothing
when the service program is running.
4. If you look at your system usage for the program test, you will
see your system being knocked to it's knees.



I ran some of these tests at a previous company. I was at running for 10
million loops for the service program I came out with something in the
order of .0000000582 something per procedure call.



After 10 minutes or so, I just shutdown the program test.



Program calls are expensive. The locking up the system part was always
interesting to me. I wonder if the operating system does some kind of
locking when it comes into the startup code for a program?



I will try this evening after work to try this on our 520 and see what I
see.