Somehow managing the page file and turning other services off in windows has turned into the Autoexec.bat and Config.sys of the modern age. Although, tweaking both autoexec.bat and config.sys was a worthwhile thing to do back in the day.
There is, or at least was, tangible benefit if you understand how it works.
A page file is, as it says, a file that's located in the root of whichever partitions that they are configured on. By default it's only configured on the C: partition and the size of the page file is variable, managed by Windows according to system demands. The page file is equivalent to a swap partition, for the Linux and BSD users out there.
Manually configuring the page file has a number of benefits, if you know what you're after (and you're using HDDs):
* You can specify a size, fixed or variable, for your page files. By default Windows allocates a fairly small page file, and if your page file use exceeds that allocation Windows has to allocate more space on the fly. This takes time, especially if the page file resides on a HDD. If you configure a fixed size, or a variable size with a large minimum size, you don't need to worry about that dynamic allocation which translates to more performance. Another benefit to a fixed page file is that you can have the page file occupy one continuous area on a HDD platter, for better access times and thus better performance; a dynamic allocation more often than not leads to a fragmented page file and thus worse performance.
* You can specify which partitions you want to use for your swap space. It wasn't unusual to just dedicate a partition to a page file, effectively the same thing as a swap partition, especially if your C: partition wasn't that big. This is important for the next bullet point.
* Back when we still ran our programs off of HDDs, making a partition earlier in the drive meant locating that partition on the outer areas of the platter. The outer areas of the platter travel faster than the inner areas, because physics, and faster platter speed means faster access times. By placing the page file on such a partition, the page file has better access times and thus you get better performance.
A lot of these benefits have gone away thanks to RAM becoming both cheaper and more plentiful, and the storage medium where the page file resides changing from HDDs to SSDs in general. So most people usually don't need to mess with their page files anymore.
But for people with specific needs or just a desire to really fine tune their systems, tweaking the page file by hand is still a worthwhile endeavour if you understand what you can get out of it.
The problem with this IMHO is that most users who are trying to do this do not understand a couple of things:
* The NT kernel does not overcommit; and
* As a closed-source OS, client and server editions of Windows do not use build configurations targeting embedded systems; they essentially require ample swap space. They won't run well if users attempt to forcibly minimize or disable their page file.
Every time a game comes out with performance issues caused by shader compilation or poorly optimized loading of assets, reddit threads and game forums are flooded with people claiming these nonsense fixes magically made their games perfectly smooth. It's asinine.
The thing that gets me is for all the attention gamers put on benchmarks when a new game or bit of hardware comes out to compare them, you never see benchmarks for this class of tweaks. If the benefit was so obvious, it should be easy and clear to demonstrate/repeat. Over the years a huge variety of these geek equivalent to old wives tales have accumulated, and a lot of them persist.
Comments
If I had a dime for every time people were being told to manually manage their Windows page file "for performance"...
Somehow managing the page file and turning other services off in windows has turned into the Autoexec.bat and Config.sys of the modern age. Although, tweaking both autoexec.bat and config.sys was a worthwhile thing to do back in the day.
There is, or at least was, tangible benefit if you understand how it works.
A page file is, as it says, a file that's located in the root of whichever partitions that they are configured on. By default it's only configured on the C: partition and the size of the page file is variable, managed by Windows according to system demands. The page file is equivalent to a swap partition, for the Linux and BSD users out there.
Manually configuring the page file has a number of benefits, if you know what you're after (and you're using HDDs):
* You can specify a size, fixed or variable, for your page files. By default Windows allocates a fairly small page file, and if your page file use exceeds that allocation Windows has to allocate more space on the fly. This takes time, especially if the page file resides on a HDD. If you configure a fixed size, or a variable size with a large minimum size, you don't need to worry about that dynamic allocation which translates to more performance. Another benefit to a fixed page file is that you can have the page file occupy one continuous area on a HDD platter, for better access times and thus better performance; a dynamic allocation more often than not leads to a fragmented page file and thus worse performance.
* You can specify which partitions you want to use for your swap space. It wasn't unusual to just dedicate a partition to a page file, effectively the same thing as a swap partition, especially if your C: partition wasn't that big. This is important for the next bullet point.
* Back when we still ran our programs off of HDDs, making a partition earlier in the drive meant locating that partition on the outer areas of the platter. The outer areas of the platter travel faster than the inner areas, because physics, and faster platter speed means faster access times. By placing the page file on such a partition, the page file has better access times and thus you get better performance.
A lot of these benefits have gone away thanks to RAM becoming both cheaper and more plentiful, and the storage medium where the page file resides changing from HDDs to SSDs in general. So most people usually don't need to mess with their page files anymore.
But for people with specific needs or just a desire to really fine tune their systems, tweaking the page file by hand is still a worthwhile endeavour if you understand what you can get out of it.
The problem with this IMHO is that most users who are trying to do this do not understand a couple of things:
* The NT kernel does not overcommit; and
* As a closed-source OS, client and server editions of Windows do not use build configurations targeting embedded systems; they essentially require ample swap space. They won't run well if users attempt to forcibly minimize or disable their page file.
Every time a game comes out with performance issues caused by shader compilation or poorly optimized loading of assets, reddit threads and game forums are flooded with people claiming these nonsense fixes magically made their games perfectly smooth. It's asinine.
The thing that gets me is for all the attention gamers put on benchmarks when a new game or bit of hardware comes out to compare them, you never see benchmarks for this class of tweaks. If the benefit was so obvious, it should be easy and clear to demonstrate/repeat. Over the years a huge variety of these geek equivalent to old wives tales have accumulated, and a lot of them persist.