It's one of those questions that raises its ugly head a couple of times a year, everyone makes some type of grunting noise, no real conclusion is reached and it's forgotten about until the next bemused victim asks all over again.
That question was about the Windows swap file, aka the page file, aka virtual memory. Over the years we've heard all the so-called best methods; no swap file, fixed swap file, system managed file, on the main partition, on its own partition, twice the system memory, three times the system memory, fragmented, defragmented...
A huge reason for all of this is the historical way Microsoft has tackled the subject and implemented virtual memory within Windows. The fact so many people call it the wrong thing is testament in itself to how badly understood the subject is, particularly when you consider virtual memory has been implemented in Windows since version 3.0 and has been around far longer than that generally in the computing world.
So we decided it was about time we took a comprehensive look at all the different scenarios and see which, if any, is actually optimal. Along the way we'll learn a lot and as we'll see come up with some pretty novel solutions that are immensely helpful beyond just the single goal of getting an optimised page file.
So no matter if you think you know it all or if you've never even heard of a page file before, we think you're going to learn something new along the way. From how best to set-up your page file, how to avoid the usual pitfalls, to some intriguing tricks that are just damn handy to know about.
What do people mean by swap file?
When someone mentions swap file or page file to you what are they talking about? Well, technically Windows 9x has a WIN386 swap file, while Windows NT/2000/XP/Vista/7 use a PAGEFILE file.
You can see why the two phrases are used interchangeably. However, the confusion doesn't stop there. All of this is connected to the Windows virtual memory system, which is what we're really talking about here.
Virtual memory enables an OS to virtualise the physical memory space to another storage medium, usually a hard drive. To do this both the kernel of an OS and the processor it's running on need to support the function.
Over 20 years ago that might have been an issue, but not today. The whole point is that when an app requests a block of memory it may see itself being given a block of real memory. In reality only part, or none at all, of this could be 'real' with the rest stored temporarily virtualised on the hard drive.
If an app requests memory that's stored off in this virtual world, a 'page fault' is generated, the virtual memory is swapped over to real memory in chunks called 'pages' and everything carries on.
The primary reason why this is a helpful thing is found back in the days when the amount of real memory a processor could access was limited to mere megabytes.
The virtual memory system typically works on pages of 4K, which are swapped in and out of real memory as a whole. This enabled a processor that could be limited to just 4MB of real physical memory to address potentially gigabytes of virtual memory, albeit with that data store on a hard drive.
Even today systems with 2GB of memory can easily require virtual memory and with the majority of people running 32-bit versions of Windows, 4GB is the practical physical memory accessible. So while this is a lot of memory, running demanding apps, such as an email client, productivity suite, image editing software, virus checkers and so on – this can simply go.
So with virtual memory still an issue, even for PCs with 4GB of physical memory installed, the original question still stands: what is the best configuration for your Windows page file, if you need one at all?
The plan here is to test a whole range of scenarios, some of them typical and others not so ordinary to reveal the optimal configuration for you.
