Not got time to find it right now but I've got an article somewhere in a magazine where they benchmarked Disk performance amongst other things and proved in 3 operating systems that disabling it did in fact decrease performance.
Did they include tests that involved maximum service times? They pretty much never do, though that's basically
the reason to disable the PF--that Windows disk IO tends to block everything. Did they include peak commits of their tests? If higher than RAM, having a PF would be faster, by quite a margin. If near RAM, the PF case could be slightly faster in bandwidth-type testing, due to paging out. Any fair benchmarking for disabling the PF needs to be done using more RAM than will be committed. If not, or if that can't be reasonably assured, the PF shouldn't be disabled, for reasons of correctness, rather than merely performance. Due to that, a fixed-size PF is really pointless, as well, unless you want to have a PF just big enough for a dump.
If you're not aware of your commit,
leave it alone. System-managed size has no magic tricks, but it will make it bigger if needed, and size PF access is highly random
anyway, the fuss about PF fragmentation is just

. The, "if you have X GB, then..." advice is bad, because the need (or not) depends on factors which vary by user, and memory that needs to be used always increases (oh, and um...I just skipped over the weird-formatted above post, there, the first time around). But, it's not magic, either, and cheap RAM makes turning it off a pretty viable option. Whenever I get around to upgrading, FI, unless RAM goes up another 70% or so, I will, for the first time ever,
not even be able to spend more on RAM than CPU (32GB under $300...crazy times),
and won't have any good way to use even half of it. If you're not able or willing to take the effort to figure out with some certainty if you can run w/o a PF, don't try,
and don't set a fixed-size PF, especially a small one.
Edit for edit:
Edit, It also must use it for more than crash minidumps, I've got plenty of ram in my system and monitor pagefile usage amongst other things, In win 7 I've never seen it empty, even when I tried 8GB. Right now there is no need for Windows to use the pagefile due to lack of memory, there is over 1.25GB spare (got a game loaded) but it's paged 266MB out to the disk.
It preemptively writes to the PF, in case it needs some of that memory. But, it will not go pull it back in preemptively, if tons of RAM gets freed, instead waiting until those pages are needed. Much of the PF's activity makes sense for netbooks and older computers, but use some major heuristic changes, these days, with cheap and plentiful RAM being common, rather than a resources to be conserved at all costs (likewise, with HDDs seeking as slowly as ever, increasing read-ahead by a few times wouldn't hurt, either--IIRC, they haven't change that since around XP). MS may have put many hours into it all, but they've done so assuming that RAM is expensive, when blocking IO time is much more, "expensive," these days. They used to change how they treated demand IO and the PF, to adapt to changes in hardware and use, but haven't seemed to try any such things for a 7+ years, now.