Peter,

Is this UDF in it's own PRG file and is the first executable line:

FUNCTION ICantBelieveThisIsSoSlow(...)

If so, simply comment out the FUNCTION declaration and see if it speeds it back up. I've never gotten an adequate explanation as to why this slows FoxPro down so badly, but it definately does.

>I was testing a simple date function from the command line and there was a noticeable pause before the result showed. I did some checking and it seemed that it took about 90 milliseconds for the function to execute. The code within the function required only about 1 ms to execute, however.
>
>I noticed that if I copied the function code into the test program that the time to call the function dropped to 1 ms. This led me to try copying the function FXP file into the default directory. This also resulted in a 1 ms execution time.
>
>If I leave the function in the remote directory where I store all of my general functions and place the call in a loop, the time to execute remains 90 ms for each call.
>
>I'm assuming that if I placed my test code in a project and built an EXE file that the function would be copied into the executable file.
>But I'm not in the habit of doing this for temporary programs like file conversion programs. Some of these conversion programs operate on 100,000+ records so a 90 ms delay for each record (and there could be many more than one function call) would add 90,000 seconds or 150 minutes to the run time.
>
>I'm going to experiment with copying all of the needed functions into the directory where I do the conversion runs. But I am surprised that VFP doesn't buffer these functions in some way.
>
>Peter Robinson