Fausto,

To my findings, the current versions of VFP don't need that much garbage collection as more older (also Dos) versions. However, it is still so that a command for garbage collection doesn't exist. Note that garbage collection involves the re-arrangement of memory. If it would be your case that garbage collection is needed, think of commands that will reset (i.e. free) memory the best way.
At the time this was explicitly needed, these commands were FLUSH (IMO never to use because it implies wrong app-logic), and CLOSE DATABASES. I'd advise to build in the latter at a strategic point, and test the result (when it doen't help, the result will be the contrary because of the necessity of reopening the files).

However, it would be my bet that you are dealing with the poor swap facilities (virtual memory) of all OS under W2K. W95 is the worst, and NT4 is bad too, though in a very different manner from W95 (98).
Supposed you are doing calculations only (i.e. no I/O) check your disk-access light. It shouldn't burn. If it does, the swapfile is your problem.
If you have a W2K (XP) at hand, try the EXE on that. The swap problems are not in there.

A W95 can be easily cecked for the swap problem; when you see the swap file growing and growing during the process of the EXE, you know enough.
Though from this, one may derive it is a memory leak from VFP, bet on it that it just is not; it's the memory leak of the WIN OS.

The swap file of an NT4 OS doesn't grow and grow, but will be too large from the beginning, and unnecessary page-outs and -ins are all over the place.


When cursors or other (temporary) files are involved, make sure that no heavy deletes occur during the process, while the process accesses the table within the range of deleted records. Though this is an obvious problem, you may not realize that VFP will "scan" for the first not deleted record in the range of in fact still existing keys within the file. If this is the case, have the according index with the !DELETED() For clause (or other means, like renaming the Key upon deletion).

Lastly, check your VFP-used memory upon logical mistakes in the app; if that grows and grows ... it may be your own fault {g} ... as you indicated.

HTH,

Peter

>Hi all,
>
>There's a couple of guys from a local software consulting company working on an information system that performs intensive calculations (we are talking about a life insurance company). The problem is that some of the operations take a lot of time to perform, so these people were asked to improve performance. While doing their job they found that specific functionalities take longer to perform while being on the same EXE file session. That is, if we execute the main program and ask it to perform a specific task (involving calculations) repeatedly, the response time increases contantly. If we quit the executable and re-execute it the response times return to their original values, but get increasing again each time a specific task is performed.
>
>They are blaming on VFP about this problem, but I think this is mainly caused by poor programming practices or lack of advanced knowledge of the language's characteristics. Any ideas about this peculiar behaviour? The program has been built with VFP 6.0 and is running under a WinNT 4.0 network.
>
>TIA,