There are several correct points in the answers so far but an important point has been missed.
As others have stated, disabling the pagefile does not turn off virtual memory. Address translation (through page tables) and everything we get from that (separate process address spaces, per-page read/write and kernel/user memory protection, the "no-execute" bit, etc., etc.) will still be happening.
What no one has brought up yet is that disabling the pagefile does not turn off paging IO either. Paging to and from disk will still be happening, even if you have no pagefile. This is trivial to demonstrate, at least on Windows. Disable your pagefile, reboot, start up Performance Monitor (perfmon.exe), look at the Paging IO counters under the memory object, and start running some programs.
How can that be? Because the pagefile is not the only file involved in paging or in paging IO!
What other files are involved in paging IO? Mapped files. And "mapped files" includes all code files - on Windows, primarily exe's and dll's.
When you start running a program or load a dll into an existing process, the code is not simply copied in its entirety into RAM. (The Windows API name "LoadLibary" notwithstanding.) The code file is simply mapped into your address space. It's the pager that does the reading, and it does so in response to page faults. The page faults happen as instructions are being fetched from code pages that are not yet paged in. In other words, code is demand paged into RAM like everything else in virtual memory (ie large portions of your code that don't actually get executed aren't brought in).
(I'm omitting mention of the prefetcher here, but that really doesn't change the principles described. Code is still demand-paged, the prefetcher just tries to make it happen sooner within the life of the process.)
And if some code is paged in, and RAM later gets scarce and some already-paged-in stuff needs to be "evicted" from RAM to make room for new stuff, pages containing code are just as subject to being paged out as data pages.
The only difference is that pages containing code are not often changed once in RAM, and if they haven't been changed, they don't have to be written anywhere before they are repurposed for something else. If they're reclaimed by the memory manager, and then later needed again, they can be (and are) just paged back in from the exe or dll files they came from.
Data files, especially large ones, are often accessed via file mapping too. The relevant *nix call is mmap(), in Windows it's CreateFileMapping or OpenFileMapping, and MapViewOfFile. Such mappings are often read/write. And if pages in such mappings have been modified while in RAM, then when the pages have to be evicted from RAM, they're written back to their original files. The pagefile is not involved.
Unless they were mapped as copy on write. Which I won't detail here, except to say that they're backed by the pagefile, if you have one.
For a given workload and a given amount of RAM there will be a certain amount of paging. Turning off the pagefile just means that all of it will be to mapped files, instead of some to mapped files and some to the pagefile. But it will still be happening. So you see, there will still be just about as much paging IO without a pagefile as with.
That's why turning off the pagefile doesn't affect performance much.
In fact, it can make things worse. Without a pagefile, when paging to disk has to happen, it has to happen to mapped files. Result: every not-shared page that every process has ever modified has to be kept in RAM until the process that modified it exits. Including old stale stuff at the bottoms of stacks, etc., that will likely never be referenced again. The pager just can't consider those pages for eviction (no matter how good a choice they would be) because there is no other place to store their contents.
btw, page writing is not usually much of a bottleneck. Writing to the pagefile, or to mapped files, is practically free (app code doesn't have to block while it happens; it's run in a separate thread). What slows down your real work is when the pager has to read the disk - ie when it has to resolve a hard page fault. Of course this can happen to both the pagefile and mapped files (including code files) - whatever the backing store for the faulted-to page is.
Again: The paging IO counters in Windows will tell you how much paging IO is happening. And they will not be zero without a pagefile.
As for the aspect of he OP's question that pertained to avoiding the overhead of address translation, reading page table entries and the like - the overhead is extremely small. It's been measured at less than 2%. The reason for this is that the Translation Buffer (TLB) cache does what it is supposed to.
3virtual memory is not always used – phuclv – 2018-06-13T16:54:46.520
@phuclv But even when it is not used, the MMU still have to translate the address, doesn't it? – appa yip yip – 2018-06-13T16:59:53.833
5You cannot deactivate virtual memory. Simple as that. It is part of how process separation and whatnot works. – Daniel B – 2018-06-13T17:00:33.647
2Yes the MMU will always translate addresses, as no Operating system since DOS uses actual physical memory addresses. – zymhan – 2018-06-13T17:01:46.723
2This is an excellent question for your professor. You can spend multiple semesters at college figuring out how different OSes handle virtual memory. – Christopher Hostage – 2018-06-13T17:53:40.293
“…why turning off Virtual Memory doesn't improve my computer's performance?” In “Ye Olden” days of Connectix RamDoubler on a Mac, maybe that would work. But not on a modern OS by a longshot.
– JakeGould – 2018-06-13T20:40:41.280by "Virtual Memory" above I actually mean page file Swapping, Paging, Segmentation, and Virtual memory on x86 PM architecture
– phuclv – 2018-06-14T15:23:26.250can someone explain why is this question being downvoated? – appa yip yip – 2018-06-14T23:42:24.063