Thanks everyone for the replies.

Cindy, have you tried removing the FUNCTION/PROCEDURE statements and noticed any general improvements in speed?

Jonathan


>Jonathan,
>
>Hacker's Guide (Faster than a speeding bullet section) says that FUNCTION and PROCEDURE slow things down by as much as factor of 10. They also tested DO MyFunction IN MyProcedureFile and it's also slow.
>
>I thought, "I can speed the junky code I inherited up 10 times and ask my boss for a raise!"
>
>>Thanks for the reply. I've been putting the PROCEDURE/FUNCTION statements at the beginning of all my programs, thinking that it was good programming to do so. Regardless, I guess I'll have to go and evaluate doing this due to the performance issues. You would think there would be something in the help about this issue.
>>
>>Are there any drawbacks that you know of to not put the PROCEDURE/FUNCTION statement at the beginning of a .PRG? If you had a .PRG that consists of more than one Procedure/Function, you would have to. But if there is only one Procedure/Function in the .PRG, I guess there is no reason to put the statement there.
>>
>>Jonathan
>>
>>>>I have a UDF that is used in an SQL Select that is basically the following:
>>>>
>>>>X.PRG
>>>>-----
>>>>FUNCTION X
>>>>
>>>>PARAMETERS Y
>>>>
>>>>(CODE)
>>>>
>>>>RETURN (Z)
>>>>-----
>>>>
>>>>The Select calls this UDF in the Where clause ( WHERE X(Table.Field) <= Value ). I've notice a dramatic increase in performance by removing the "FUNCTION X" statement in the .PRG file. Is this expected?
>>>>
>>>>Thanks,
>>>>Jonathan
>>>
>>>Yep...it is well know that if your program name is the same as the function name, removing the function/procedure statement from the program grealtly increses performance.
>>>
>>>BOb