A pagefile will never increase performance, but it doesn't necessarily degrade it either (with proper memory management). Running without a pagefile, however, will only tend to increase your system's instability with respect to applications requesting memory that is not available for use.
Unless your OS is particularly bad at memory management, a pagefile with 6GiB of memory should see little use. That isn't to say it won't see any use at all; IIRC MS Windows is a bit crazy when it comes to paging things out even when there is plenty of memory available. (Why, I'll never know.)
However, what happens when you don't have the pagefile in use may be reason enough to enable it: hard crashes. Most apps expect to receive the memory they request. When they don't, they crash. (Ah, but the good-old-days of having to live in a few thousand bytes are gone..., and for all too many developers, so has the practice of dealing with memory management.)
If an app is built right, it'll fail nicely. (With luck, it'll not fail at all. But don't count on it.) With most apps, you'll have a fantastic failure on your hands. Furthermore, the more apps you have that come close to that limit, the more likely you are to see system-wide instability.
Case from my own experience. Windows XP, 4GiB, No page file. Perf was great. Until we started getting close to the 4GiB limit. Then things went nuts: apps would crash, menu items would only partially appear (or not at all), buttons would do nothing, etc. I switched back to the page file, even though performance was worse with it -- overall stability was simply better and more important.
Now, perhaps you don't use any apps or do work in your apps that would push 6GiB, but I can think of a few situations where you might get close: video editing, photography editing, audio mixing and production, etc. -- essentially anything where you are dealing with a lot of data (either working with, or streaming). When that data exceeds your memory capabilities, chances will be good that your app will just go "poof".
By definition, inactive memory is memory that is ready to be paged out, and paging it out might involve writing it to swap. This is not any kind of problem or issue that should be optimized; it is in fact OS X working as designed.
Unfortunately, tech support writers are not kernel developers, and the Apple Knowledge Base support article quote is just wrong when it claims that Inactive memory is memory unused by programs. When you quit a program, all of its resident memory becomes Free; it doesn't stop over in Inactive. However, the second link to the developer site describing how memory management works is a good resource, if read fully.
There are many misconceptions about what "inactive memory" means in OS X. Contrary to the misconceptions, not all inactive memory is empty, unused, cache, or purgeable. In fact, Active memory can be cached or purgeable as well, if it has been recently accessed. Much inactive memory also contains data that cannot be simply discarded. If it were discarded, programs would crash, because the discarded pages would have contained valid data (as the quote from the OS X developer's side says,) and programs expect data they have stored in (virtual) memory to not just disappear.
Inactive memory contains the same types of data as active memory. The only difference is that OS X has noticed that some chunks of memory have not been read from or written to in a while.
The reason that OS X classifies some memory as inactive and other regions as "active" has to do with paging out. When memory runs low, you are going to have to page out some data. The question is, which data? If you page out data that a program turns out to immediately need again, it wastes time and accomplishes nothing. So you want to page out memory that a program won't immediately need to use again.
Anticipating which pages are likely to be unneeded in the future is difficult because a program can use its virtual memory however it likes and not tell the OS anything about what its plans are. But as a heuristic, most programs are "sticky" in their memory usage; if they haven't used some piece of memory in a while they are likely to continue not using that memory, and likely to continue using memory that they have recently used.
So when the OS decides to page out some data, it takes the strategy of swapping pages that haven't been used recently. This is why OS X sorts the memory that is being occupied by programs into two piles of "active" and "inactive." The above posted link to the Developer site, if read fully, tells how that process happens:
- When memory starts getting low, the OS starts going through the active memory pages, and sets a flag on each.
- If a program reads or writes to a page, the flag is cleared.
- If, after some delay, the flag is not cleared, that page gets sorted into the "inactive" pile.
- If an "inactive" page is accessed by its program, it is put back into the "active" pile.
- When memory runs out, the "inactive" pages are paged out.
Note that this sorting process to decide which memory to swap out is similar across all modern operating systems. Linux has the same two lists of active and inactive pages, as described in Understanding the Linux Virtual Memory Manager. Windows might use something a bit different with more than two classes of recency; I can't find a recent, reliable technical description at the moment. More implementations are discussed at the Wikipedia page entitled "Page replacement algorithm". The only difference with OS X was how the statistics were shown: someone decided it would be a good idea to show separate numbers for active and inactive in top
or Activity monitor. In retrospect this was probably not such a good idea (and this has changed in OS X 10.9.)
This process of setting and clearing flags and maintaining active/inactive heaps does take a little bit of processor power. For that reason, OS X doesn't do it when there is a lot of free memory. So the first programs you start up will show up as all "active" memory until free memory starts running low.
So, as you start from a blank slate, and open more and more programs, you can expect to see the following progression in Activity Monitor:
- First, there is a lot of "free" memory and very little inactive. This is because the memory flagger hasn't started running.
- As the amount of free memory drops, OS X will start running its memory flagger, and you will start to see the amount of "inactive" rising. Each bit of "inactive" was previously "active."
- When you run out of free memory, pages from the "inactive" pile will be paged out. The memory-flagger will also be running full tilt sorting out memory into active and inactive. Typically, you will see a lot of "inactive" while swap is being written to, indicating that the memory-flagger is doing what it is supposed to.
Pages must be classified as inactive before they are swapped out. That is what the quote from the Apple Developer site means when it says "These pages contain valid data but may be released from memory at any time." This is in opposition to Active pages, which will not be released until after they have been demoted to Inactive. There are various ways of releasing pages; if the page was mapped from a file and has not been modified, it can be deleted immediately and re-read on demand. Similarly if it is memory that had been previously swapped out and not modified since it was swapped in. Programs can also explicitly allocate cache and purgeable memory, to store data that can be forgotten and recreated on demand (but the reason a program would allocate cache is if it takes significant time to recreate that data.) But much of inactive memory is memory that programs have written valid data to, and paging out this data requires writing to swap.
Therefore looking at the amount of "inactive" memory in Activity Monitor, and seeing that there is a lot of inactive at the same time as the computer is writing to swap, only tells you that the system is working as designed.
There is also a confusion between inactive memory and file cache. I'm not sure why there is that confusion, because Activity Monitor already lists them under separate headings. Cache is memory used to store recent data that have been read to or written from the file system, in case they need to be accessed again. When memory is low, OS X does tend to get rid of the the cache first. If you have swap thrashing, and Activity monitor shows a big pile of cache (NOT inactive) then that would be a problem. But inactive memory is a different thing.
If in doubt, ignore the distinction between "inactive" and "active." Regard them as being one lump of "memory used by programs" and add the two numbers together. This is what every other operating system does when telling you about memory usage.
NOTE for OS X 10.9: Mavericks introduced "memory compression" which is, more or less, another layer of swap. Active pages now get classified inactive, then compressed (which might show up as Kernel memory depending on what tools you are using,) then written to swap as memory usage increases. Mavericks has also has stopped showing separate numbers for active and inactive in Activity Monitor, since it turns out not to be a useful thing to look at, especially given the misconceptions surrounding it.
Best Answer
Windows XP flushes minimized applications to disk like crazy.. try it yourself, start downloading a large torrent and minimize everything. Pretty soon almost all of your RAM is used as file cache for the torrent instead of your other applications. Disabling the page file will prevent this behavior.
In Windows Vista and Windows 7 though, the system handles this scenario much, much better.. so I'm not sure disabling the page file in these versions will do much of a difference.
Some games require you to have a page file even when it's not really needed, I noticed this recently when trying to play a game demo I downloaded from Steam. Even though I had 6 gigs of RAM available the game refused to start until I created a tiny, tiny page file.. sigh
Personally, when I have plenty of RAM, I prefer to go without a paging file.