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