Thanks Craig,

The project is seasoned - and I didn't make any changes to the pertinent stuff. I did a little array to store polynomials needed for a cubic spline - but that stuff is fast.
.
The project uses DBFs. XMLHTTP fetches a web service CSV and parses the CSV to a DBF cursor. The speed problem is not there.

The performance issue presents when the cursor is scanned. The values in the cursor are fed to "pricing" routines, so called derivative or quant functions that return a single value which is then stored in a source cursor field.

The Task Manger Histogram reports 100% while the calculations crunch for both.

My thinking is that the registry has to work harder because the tested EXE that overlays the MSI (installed) EXE. One guess is the installed registry pointers are invalid and addresses have to be "searched" for when the "overlaid" EXE is tested in the Program FIles folder.

It's just algebraic procedures (an over simplification for sure) in a procedure file, Does the registry address each procedure (symbol) name in the MSI at install?

One or two of the procedure files are approaching 2000 lines - maybe it's a paging issue. I know in dBase IV big procedure files cause unexpected and unexplained problems - even when compiles to a standalone EXE.

I might be over doing it with the SYS(3050) and the max stuff in config FPW.

The IDE FXP crunch performing better than the EXE crunch is unexpected - seen it before - it went away - the cure may be to simple rebuild the MSI and do a proper install.If it was an issue of doubling up or multiple passes then it seems that would present during the IDE FXP tests.

Any thoughts appreciated.

It's not

>Is the MSI and IDE on the same PC, running against the same database?
>
>>Hello,
>>
>>When testing new EXEs, my practice is to save the build to the folder of the the most recent version (MSI) the new EXE will replace. I use this practice for a variety of reasons: One is to avoid cluttering up and then having to cleanup default DBF store states. Another is to take advantage of any data the legacy MSI might contain for testing.
>>
>>I know there is a difference in the behaviors of an installed (MSI) EXE and an EXE that runs in the IDE (VFP window).
>>
>>For example, this particular project implements some very tedious calculations. A few years ago some really tedious iterations were added. IDE testing raised an ERROR 78 (so called domain, or exponential function error). When the MSI was tested, ERROR 78 never happened. The solution (i think) was to make sure a copt of the C7runtime DLL was in the development folder.
>>
>>My issue is speed. When testing in the IDE using just FXPs (not an EXE), the application seems to crunch the numbers about 3 times faster than the EXE copied into the MSI folder.
>>
>>Before each computational pass the app implements:
>>

SYS(3050,1,1)
>>SYS(3050,1,uiFGMemory)
>>
>>* Note: uiFGMemory=INT(VAL(Sys(3050,1)))

>>
>>Config.fpw looks like this:
>>

resource=off
>>refresh=0,0
>>help=off
>>progcache=0
>>mvcount=65000
>>stacksize=65000

>>
>>The Legacy app seemed to deliver better performance when it was initially installed (too lazy to build a test MSI to verify).The computations are the same (TRY CATCH routes to less tedious alternative computations should the "desired" computations cause stack problems)
>>
>>Is my practice of over writing an MSI installed EXE effecting something in the registry that would explain why the FXP(s) in the VFP IDE window out perform an overwritten EXE in the MSI Program Files folder?