>>>Hey all
>>>
>>>I've got a UDF that is something like a cross between SEEK and LOOKUP(). The problem is - calling a UDF is slower than native functions.
>>>
>>>The function is liberally scattered everywhere. The parameters do not match the LOOKUP function, which would have been virtually perfect. I know a search and replace might work, but that will break a lot of code too.
>>>
>>>So - an idea has been tickling around my mind,
>>>
>>>Given the existing call ... MYSEEK(seekthis,"inalias","thistag","returnthis")
>>>
>>>would it be possible to #DEFINE and make the above into something native at compile time?
>>>
>>>Thanks
>>
>>Hi Mike:
>>
>>I wouldn't recommend the #define idea, and the UDF, depending on the implementation, shouldn't have a notable performance difference of the SEEK() + RETURN field
>>
>>Can you post your UDF implementation? The way I see it, should be something like this:
>>
>>

>>*-- MYSEEK
>>LPARAMETERS tcValue, tcAlias, tcTag, tcReturnField
>>
>>IF SEEK( tcValue, tcAlias, tcTag )
>>   RETURN EVALUATE(tcReturnField)
>>ELSE
>>   pcFieldType = TYPE(tcReturnField)
>>   RETURN ICASE( pcFieldType = "L", .F. ;
>>      , pcFieldType = "T", {//::} ;
>>      , pcFieldType = "D", {} ;
>>      , pcFieldType $ "NIFB", 0 ;
>>      , pcFieldType = "Y", CAST(0, Currency) ;
>>      , "" )
>>ENDIF
>>

>>
>>Regards.-
>
>Hi Fernando
>
>Actually there is a large overhead calling a UDF compared to a native function, even if the UDF does nothing. Calling methods is worse. You can prove this to yourself very easily. Make a myseek.prg that takes the parameters of seek and call seek inside it. Then call seek directly. The difference is overhead.

from one perf nut to another (and to Fernando) - actually the number of parameters in the UDF call makes it worse. Calling a UDF with no parameters (if those are loop invariant for instance) where the UDF recurs to private memvars declared down the program stack is bad coding but much faster.... One of the quirks Vfp shares with Python compared to Java or C#