>>>>Why are you arbitrarily storing multiple procedures/functions in a single .prg? This does not help the compiler. If you build separate .prgs per function the exe will run them faster, than if it has to dig into other files first.
>>>
>>>another myth,
>>>
>>>Consider:
>>>
>>>

>>>SET PROCEDURE TO MyFunction3
>>>
>>>nSec = SECONDS()
>>>FOR nT = 1 TO 1000000
>>>	x = Myfunction()
>>>ENDFOR
>>>? "Myfunction, same proc file", SECONDS() - nSec
>>>
>>>nSec = SECONDS()
>>>FOR nT = 1 TO 1000000
>>>	x = Myfunction2()
>>>ENDFOR
>>>
>>>? "Myfunction2,  seperate Prg", SECONDS() - nSec
>>>
>>>nSec = SECONDS()
>>>FOR nT = 1 TO 1000000
>>>	x = Myfunction3()
>>>ENDFOR
>>>? "Myfunction3, set procedure", SECONDS() - nSec
>>>
>>>WAIT window
>>>
>>>FUNCTION MyFunction()
>>>RETURN .T.
>>>

>>>
>>>Outcome (ran as EXE) :
>>>Function in the same source file 0.2 seconds for 1 million calls
>>>Function as PRG exactly the same: 0.2 seconds for 1 million calls
>>>Function as part of procedure file using SET PROCEDURE: 0.185 for 1 million calls.
>>>
>>>There is ABSOLUTELY NOTHING to gain performance wise to split function up into procedures.
>>
>>Walter, while I not say there is many use of the prg procedure thing, your test setup is not the best. You would need something comparable and to much depends on CPU wonders those days. Your tiny code will simply run inside CPU cache, optimized by CPU whatever. The dust on the CPU cooler might have more influence.
>
>He also did not show the impact of DO function IN library, and the impact of many libraries. Regardless, once all the libraries are loaded, the code deep inside only invokes the specific function, which is exactly how I store mine.

DO function IN library, suffers from the same problem as NewObject(). It does have a severe performance hit when using it in tight loops, but is perfectly fine if you need to use it in other cases. There is no need for the IN clause if you are using SET PROCEDURE.