[0x1d7]

This is almost always a bad idea.

If no memory is available where a page file would make a difference, this leads to application crashes instead. A crash is (usually) worse than paging.

Certain applications, Photoshop being the historical example, will outright fail to run with no page file present.

[szmarczak]

> this leads to application crashes instead

Same happens if the page file is full. In that case, why don't those programs use disk directly instead?

No such problem would've ever occured if programs hadn't allocated more than they actually use.

[toast0]

By default, windows uses an expandable page file.

Typically, performance drops enough that the user kills the program or reboots before the page file expands to fill the disk. And other threads here suggest there is something that will prompt users to kill programs in states like this.

> No such problem would've ever occured if programs hadn't allocated more than they actually use.

That's part of the issue, but sometimes things do in fact use too much memory as well as allocate too much.

Another part of the issue is that few programs are built to handle allocation failures.

And then you have a metrics issue. There's not really a good metric to know when you're out of memory, other than performance collapse. If your applications don't use disk, it's not too hard; but when they do use disk, performance will collapse once there's insufficient memory to provide the disk caching needed. In my experience, adding a small swap and monitoring swap i/o can be pretty helpful, and a small swap doesn't tend to allow long thrashing when memory use grows. But that's not universal and everybody loves to hate swap these days.

[quotemstr]

> Typically, performance drops enough that the user kills the program or reboots before the page file expands to fill the disk. And other threads here suggest there is something that will prompt users to kill programs in states like this.

Not in the age of NVMe it doesn't. Swap is fast now. Plus, at least on Linux, you can put zswap in front of the regular swap and introduce an even faster level of memory hierarchy and thereby make page-outs even more profitable.

[0x1d7]

Swap is not fast. Faster than it was, yes, fast, no.

[swinglock]

Windows does memory compression too.

[quotemstr]

It's been a while since I've looked at it, but IIRC it doesn't model the compressed RAM as a special swap tier, which IMHO is a pretty elegant way to look at it.

[0x1d7]

Your argument falls flat when a page file can be multi-GB and automatically grow. And if your application admin was competent, memory monitoring would be part of the application monitoring stack.

An application that grows in such a way (besides having backing stores for memory-mapped files, as well) will often perform so poorly that it requires addressing (adding RAM, looking for application faults, etc).

A page file is insurance, one that can last you much longer than available system memory.

[szmarczak]

> memory monitoring would be part of the application monitoring stack

You don't need it if you have everything allocated upfront. TigerBeetle does this, everybody else can.

Using something like Rust is already a huge win when compared to shipping a browser or running Node.js.

> Your argument falls flat when a page file can be multi-GB and automatically grow

This doesn't solve the original issue and only masks the underlying problem.

[0x1d7]

> This doesn't solve the original issue and only masks the underlying problem.

You're moving goal posts. No, a page file doesn't solve the problem of a misbehaving application, but it does solve the problem of an app crash because no more VAS allocation can be made.

You should really dive into Windows Internals. Only misinformed gamers turn off page files.