Virtual Memory Fix

Hi,

It does sound like the original poster could benefit by more memory.

On the other hand here are my thoughts on virtual memory ... The hard disk serves as an extension of physical memory as virtual memory, commonly referred to as the paging file or swapfile. When an operating system runs short of physical memory, it pages out the least recently used data to the hard disk. When that data is required, the operating system will swap it with the least recently used data in physical memory. A swapfile functions by swapping entire processes from physical memory to the hard disk. A paging file functions by moving "pages" of a program from physical memory to the hard disk. Because swapfiles and paging files both create virtual memory, the terms swapfile and paging file are generally used interchangeably, although with the advent of Windows 95, only paging files have been used. The swapfile grows and shrinks as needed, but this activity consumes CPU cycles, and prevents the hard disk from performing any other tasks until the resizing activity is completed. As the swapfile grows, it can become fragmented across the hard disk. The extra "housekeeping" required to monitor and manage the swapfile's size and fragmentation can cause Windows to become sluggish. The concept of a fixed (same minimum and maximum size), permanent swapfile arose from the notion that a swapfile of a fixed size would not have to be managed (constantly resized) by Windows (a good thing) and would remain contiguous, that is unfragmented (also a good thing). The flaw in the reasoning, however, becomes apparent the first time that more virtual memory is required than accounted for by the size of the permanent swapfile. The result is an out of memory condition (error message). The objective should be to establish an unfragmented swapfile of a sufficient size. With an unfragmented swapfile, Windows can expend time and resources using the swapfile instead of managing it. You'll read various theories concerning how to set up the swapfile. One popular misconception often proposed is to make the swapfile a permanent fixed size (same minimum and maximum size) given multiplier (generally 1.5 or 2.5) times the size of a PC's physical memory. This factor (multiplier) concept is flawed because the addition of physical memory diminishes the requirement for virtual memory. There's an inverse correlation at work here. There is an alternative form of swapfile called a semi-permanent swapfile consisting of a permanent (minimum) and a dynamic (maximum) swapfile component. A semi-permanent swapfile provides the user with the advantage of never running out of virtual memory, but with a potential performance penalty to be exacted. The permanent (minimum) component does not change in size and remains contiguous (unfragmented). The dynamic (maximum) component resizes itself as required, but, in the process, can use any available free space on the hard disk, which eventually results in a swapfile that becomes fragmented. Performance degradation of the swapfile and system overall is the penalty paid. Both a permanent and a semi-permanent swapfile perform equally, until the virtual memory requirement exceeds the permanent (minimum) component of a semi-permanent swapfile. The only way to circumvent the performance degradation penalty is to ensure that the permanent (minimum) component the semi-permanent swapfile is sufficient to meet the virtual memory requirements, but then what's the sense of creating a semi-permanent swapfile? At this juncture wouldn't it just make sense to create a sufficiently large enough permanent swapfile as needed? granted some experimentation is required, but worth the effort.

Jim McNamara