The information in this article applies to:
SUMMARYVisual FoxPro handles memory management differently from previous versions of FoxPro. With FoxPro version 2.x, FoxPro had to pre-allocate one or more blocks of memory at startup. This is demonstrated by using MVCOUNT and MEMLIMIT. Visual FoxPro uses a more dynamic approach to memory management. MORE INFORMATION
In Visual FoxPro, a small footprint is allocated and the reserved memory
pool is dynamically increased as needed. When free contiguous space in the
currently allocated blocks used by Visual FoxPro becomes low, Visual FoxPro
will try to compress the memory block. If Visual FoxPro still needs more
memory after compression, it requests another memory block from the
operating system.
Memory PoolsWhen Visual FoxPro starts, it creates two memory pools (FOX USER and FOX BUFFERS). The FOX USER area stores memory variables, and FOX BUFFERS stores strings that are embedded in the product as well as any structures that are related to files that are open. Visual FoxPro pulls memory from three existing Windows resources - OLE, USER, and GDI resources.Example Showing How Memory Pools Are UsedWhen a user opens a form owning a private DataSession and that form is instantiated, Visual FoxPro uses memory from the FOX USER pool to store information about the session and properties of the form. The FOX BUFFERS pool is used to cache parts of the tables that are open in the DataSession.There is no Visual FoxPro command that forces the FoxPro memory manager to release the reserved memory blocks. The commands CLEAR ALL, RELEASE ALL, CLOSE ALL have no effect. Additional query words: VFoxWin
Keywords : kbenv FxenvMemory |
Last Reviewed: August 16, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |