>>>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.

I don't see how that could be a factor of any significance in this matter.
Once a procedure is loaded in memory, it stays there, ready to execute. Whether or not it is stored in a PRG does not make any significant difference.