Memory boosters, optimizers, and washers --- whatever the name, they all do the same thing: free up physical RAM. They accomplish this by forcing RAM to be 'paged out'. That means, the memory is taken from RAM and put into the page file, which exists on the hard drive. Does this make your computer run faster? The short answer is No. In fact, just the opposite is usually the case.
You must first understand what virtual memory is. All modern operating systems utilize it. Virtual memory is essentially memory that can exist either in RAM, or on the hard drive or other storage medium. That is why it is virtual memory, because it can be backed by any storage medium, not just RAM. This allows for your system to use an almost infinite amount of memory, by swapping pages between the page file(s) and RAM. When memory isn't being used, and RAM space is needed by other processes, that RAM is paged out to the page file (or swap partition in the case of many non-Windows operating systems - but we'll refer only to the page file since we're talking most about Windows). Windows applications only see virtual memory. They have no concept of how much free RAM is available, nor should they care. They don't know whether memory they've allocated is currently stored on disk or in RAM. The Windows operating system transparently handles all this.
When virtual memory is accessed, the system does a quick check to see if that page of memory is already in RAM. If it isn't, then a hard page fault occurs and that memory is loaded from the page file (or swap partition, etc..) back into RAM. This operation has a great amount of overhead since your hard drive must seek to the right location in the page file and read the necessary page(s). In general you want to reduce the number of hard page faults as much as possible. There are also soft page faults, which incur less overhead than hard page faults, but I won't get into detail to avoid reader confusion. A soft page fault is simply where the needed page of memory is already located somewhere in RAM, and can therefore be mapped into the accessing process without having to read from the page file.
Virtual memory is organized in pages. A page is a block of a few kilobytes of memory (typically, 4KB). The process of moving a page of memory from RAM to the page file is calling 'paging out', or 'swapping out'. Conversely, the process of moving a page of memory from the page file to RAM is called 'paging in' or 'swapping in'.
Windows manages virtual memory so that commonly used pages are attempted to be kept in RAM and less commonly used pages are stored in the page file. Since RAM is your computer's fastest storage medium, you want to make maximum use of it. You WANT to keep it full. In fact, the RAM that isn't used by your running programs is usually filled with cache data. Windows attempts to always make as much use of the RAM as possible.
Available virtual memory is limited only by the size of the page file(s). In this way, the system can use gigabytes of memory even if the RAM is only a few hundred megabytes. Often, the page file is configured to dynamically grow when needed. In such cases, available virtual memory is only limited by the free space on the partition(s) the page file(s) exists.
Memory optimizers temporarily force all possible pages in RAM to the page file. Thus, the amount of free RAM is increased, but the amount of virtual memory in use is not affected. Later (or immediately), when the applications whose memory was paged out access that memory, it must be paged back into RAM -- incurring substantial overhead.
The only benefit from these applications is that if you were to load a program immediately after you've paged out all available memory, it might load faster in some cases because pages of RAM are already available and don't need to be paged out in order to make room for the program. One way to look at this scenario is that the cost of freeing RAM is done before the program loads instead of as the program loads. However, this benefit is negligible and is more than paid for later when the RAM that was paged out must be paged back in.
The memory that is paged out must be paged back in for you to use the other applications running on your computer. Thus, when you click on a minimized application, for example, it takes longer to restore its window because more of its memory must be paged in. Furthermore, pages that are used by the operating system components or background processes are often paged back in immediately after the memory 'cleanup'.
These memory optimization applications interfere with the ability of Windows to efficiently manage virtual memory. Furthermore, many of them don't even free RAM in a proper way. Often, they do so by simply allocating as much RAM as possible, forcing Windows to page out the memory of all other applications. The correct technique is to use the SetProcessWorkingSetSize API on each running process to force as much virtual memory to be paged out as possible.
These programs are ridiculously easy to write and sell. They usually don't live up to the claims they make. Savvy users should beware these applications, and for that matter, any other software that makes outlandish claims.
There are many misconceptions propagated by the authors of these applications and adopted by users who don't know any better. Here are a few:
| Myth | Truth |
| Memory optimizers increase overall performance | False, as noted above in this article. They often decrease overall performance. Paging out all possible memory just forces it to be reloaded once it is needed again. |
| Programs crash because of lack of physical memory (RAM). | Programs only have access to virtual memory (exists in RAM as well as page file). They don't actually ever directly allocate physical memory. A crash due to the inability to allocate virtual memory is extremely rare. Regardless, these applications do not increase the amount of free virtual memory and therefore have no impact on programs that crash as a result of the inability to allocate memory. |
| RAM must be defragmented | This is completely false and quite absurd. Hard drives need defragmenting because the read head must seek the proper location on the disk to read from a file. If the file is located in pieces all over the disk, that means more seek time. In the case of RAM, there is no seek time, so defragmentation is absolutely pointless. |
| Unused DLLs are unloaded | This is simply false. When a program terminates, all DLLs it used are unmapped (as is its entire process space). Upon program crash, these DLLs may not be notified the program is closing, but they will still be deallocated from the crashed program's address space. A shared DLL may still be in use by other programs and be mapped into their process spaces, but that has nothing to do with the issue. When a DLL is no longer mapped into any process space, it ceases to exist. DLLs can not exist by themselves in virtual memory. They must be mapped into some process space. |
| Other unused resources and memory are unloaded. | This is simply false too. Nothing is left in memory when a program crashes and these memory washers have no way of knowing what a currently running program needs and doesn't need. |
It is best to leave the management of virtual memory to Windows and not take it into your own hands. Any benefit from these programs is an illusion and temporary. You incur the penalties of paging memory back in sooner or later, even if it appears that the program you run after the cleanup loads faster.
If you decide on using one of these programs because your needs do
actually warrant it, at least find one that pages out memory in a proper way
(SetProcessWorkingSetSize API) instead of allocating gobs of memory to itself. I do not know which of these
applications do it properly and which don't, but the less gimmicky they look,
the better they probably are. An application like this written by a
professional at least stands a better chance of performing its tasks in an
optimal way and causing less performance degradation.
Jeremy Collake
Bitsum Technologies
http://www.bitsum.com