Hi Al,

>If you've got a highly tuned app taking 5+ hours to run, that's a lot of crunching. You're right, if you're working with largish data sets you can benefit from more RAM for disk cache - like I mentioned earlier with video editing. You might be a good candidate to run a 64-bit Windows OS with, say, 16GB RAM. Although VFP would run using only 0.25GB on WOW64, hopefully the host OS would snoop the disk I/O and cache the full 12GB eventually. Get rid of those expensive cache misses entirely.

The app is called by an exe not under my control - and this exe has some quirks I hesitate to twist even further, as the app does call into some objects of the exe. And we must - at least for the billable conversions - run under 32Bit XP or W2k as even Vista is running but has no official stamp of approval.

Running in a small VMWARE XP/32 machine on a 12GB Linux/64 was faster than the native XP32 - but not enough to make it our standard mode of operation ;-) For debugging and development the fastest way is to have a huge RAM disk for cdx and some compressed dbf working on memory the OS is not even aware of.

>You're probably one of the few business users who can actually make use of a fast CPU and fast RAM.

CPU yes, RAM speed is not a great factor, RAM size is.


>Out of interest, what are the types of errors you see with VFP when you give it more than 256MB?

Observable symptom: App fails to load flls. Therefore, sadistic developer (me) stresses the App by loading/releasing a not needed fll regularly to see if the error is "in the system". The fll is clearly availabe (is on local and gets verified before by fileToStr) and has been loaded and released regularly at each%%-step at least once. The amount of times load/release cycle has run is NOT a factor (looping such cycles for the fun of it or adding a test calls in other places as well gets the error still at about the same amount of processsed data). Running under different Memory layouts does change the amount of data to be processed before the error crops up. Error is quasy - stable (will show up in over 90% within a couple of thousand data operations if the same data set is run again but sometimes will finish without a problem). Gremlin activity loosely correlated with sunspot cycles ?.

Declare Dll will be unstable if flls fails to load, as well as sometimes printer driver trouble has been seen if running on to report section.

The app *can* exhibit a memory leak on some data sets - as there are MANY c-fll's and a bunch of activeX routines already in the calling exe, I am trying to isolate an observable pattern running with workarounds for the C code done in vfp or without the C functionality (I can break encryption from within any time I want to anyhow...) enabled - no luck yet. Not even sure there is a connection between those 2 facts, but this is nagging me as well. Error is seen regularly even on machines with only 2 Gig of physical RAM and no RAM disk loaded and vanilla XP WS, even without virus and Firewall as the cable is pulled. Video card changed experimentally from ATI to nVidia to be sure no driver trouble from that side is responsible.

The fun of complex systems...

regards

thomas