I made quite a few changes to some inherited code, and the users noticed it, but I never measured individual changes.

I also added some indexes, re-arranged some loops, etc.

>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