Trog100, read ALL OF THIS, because the "devil's in the details", & an experiment you can perform & observe, yourself, will illustrate to you JUST HOW OFTEN PAGING OCCURS & how often "Virtual Memory" on disk in pagefile.sys is really used... here we go:
i have put this to the test many times.. windows will only start to use its fake hardrive memory when it runs out of the real stuff..
Not true, & I'll let you see for yourself how it is not. Explorer.exe is a PERFECT EXAMPLE thereof in fact, & its page faults will show you this (it is paging, all the time nearly, generating "page faults" & this is the KEY to this statement of mine - even though unused RAM is present? It is PAGING!)
You'll see below, perform the test I am noting... you'll see I am correct on this note.
windows does not use its swopfile unless it has to..
Untrue, and the experiment I am about to have you do? Will show you otherwise...
You're always using it whether you know it, or not.
Again: This IS the nature of these machines using the OS that they do... modern, virtual memory utilizing OS like Windows NT-based ones, & Linux (& others too).
In fact, let me FINALLY prove this to you, by letting YOU prove it to yourself, ok?
We'll do a little experiment below:
we have real physical memory (the hare) and we have the windows swopfile (the tortoise).. the two dont work that well together..
AGAIN: First of all did you know, that the pagefile.sys is "RAW WRITTEN" & bypasses normal filesystem access patterns & API calls? It read/written to FASTER THAN ORDINARY READ/WRITE ACCESS for your files & programs because of it & also because it is OS kernel subsystem driven (memory manager & iirc, partially cache mgr. they operate superclose with one another).
Au contraire, mon frere... They work well together & stop you from getting "out of memory" errors & the real "raison d' etre" for Virtual Memory Modern OS designs!
VERY well in fact, especially considering HOW the pagefile.sys is accessed (faster than normal read/writes to ordinary files on disk in fact)!
Let me give you an example you can SEE for yourself:
A simple way to see this, is to start a NEW program! Leave it onscreen as a normal sized window.
Then, open up Taskmgr.exe, & get into its PROCESSES tab...
Use its VIEW menu, SELECT COLUMNS submenu, & check off "Virtual Memory Size", "Memory Usage", & "Peak Memory Usage", & "Page Faults Delta" columns. They will show in the processes tab as VMSize, Mem Usage, Peak Mem Usage, & Page Faults, respectively.
Go back to PROCESSES tab in taskmgr.exe & pay close attention to the new program you started by first hiliting its row, & then, note the VMSize & pagefaults columns!
(That is what is allocated to that process in Virtual Memory (& again, keep in mind: THAT ALL MEMORY? Is "Virtual" in today's OS', both RAM in chips AND pagefile.sys space combined)).
Now, minimize the process to the startbar!
Tell us what happened to the numbers in the Mem Usage column...
(They went down for that program you just minimized, didn't they?)
Now, when you restore that window (to normal size) they go up again.
Where do you think the RAM went for that program when you minimized it?
Did the program just "get rid of it"??
NO!
(EDIT PART - possibly SOME, this is known as "discardables" to program, but usually iirc? That happens when an app starts up, or dumps data it was using, but no longer is anymore, currently).
NOTE - this doesn't happen on Win9x, I never saw it happen (while doing the min/max of a window program running test)...
THIS, is a BIG diff. in Windows-NT based OS exists here from my experiments in the past w/ Win9x vs. NT!
It paged down to disk, in pagefile.sys, what is not immediately used resources it has!
(Things like its screen images, buttons, tabs, controls of all kinds etc. from its interface & more when NOT visible/normal window view OR maximized, vs. minimized)
Right down to your Pagefile.sys & it went into the block of size allocated to it (shown in taskmgr.exe as "VM Size" in fact!)
What can illustrate that in taskmgr.exe?
The PAGE FAULT column!
As you minimize, maximize/restore a Window? You'll see it move LIKE MAD!
Here is what a "page fault" is by its definition:
--------------------------------------------------------------------------------
An event that occurs when a thread refers to an invalid (out-of-date) VM page. The VM manager must refresh the page from the page file. See VM.
docs.rinet.ru/NTServak/glossary.htm
A page fault is an exception which is raised by the memory management unit when a needed page is not mapped in physical memory. This exception is passed on to the operating system which will bring the required page into physical memory.
en.wikipedia.org/wiki/Page_fault
--------------------------------------------------------------------------------
That entire memory block is still claimed by the process, but paged out because it is no longer the foreground process & its resources (window elements like buttons, tabs, etc.) are no longer in use if not visible on screen!
They got paged out to disk into that VMSize allotted area which you have visible!
Explorer.exe especially (your GUI shell)?
You'll note it is nearly CONSTANTLY generating page faults & thus, paging its data in & out of the pagefile.sys - EVEN IF FREE, UNUSED RAM, IS PRESENT!
VM Size, iirc, is based on its PEAK MEM USAGE (usually @ startup of a program, it takes a LITTLE BIT MORE to load itself than it needs to keep running from then onwards).
i also know that if my system runs out of real memory whilst playing a game my game will instantly become totally unplayable..
Again, did you know, that the pagefile.sys is "RAW WRITTEN" & bypasses normal filesystem access patterns & API calls & is driven by preferred CPU status OS kernel subsystems in the OS kernel memory mgr (ring 0/rpl 0/kernel mode operations, get pref. over usermode/Ring3/RPL3 stuff)?
I.E.-> It read/written to FASTER THAN ORDINARY READ/WRITE ACCESS for your files & programs because of it.
Secondly:
Your program that is generating PAGE FAULTING (more details exist on that above, important & ones you CAN SEE)?
It is thus, always "useable" (albeit possibly not enjoyable if paging data in & out of the pagefile)... but, it will NOT just "die" either as long as there is diskspace open for pagefile.sys growths, that is.
It will contine to run & not throw "out of memory" style errs because of it...
It will run, albeit more slowly than if it was TOTALLY in RAM & had all of its memory requirements satisfied by PURE "RAM IN CHIPS"... not paging it in & out of RAM in 4kb/4096 bytes increments.
When you have a foreground process demanding more memory than is physically present in RAM chips on your mobo that is unused then, the memory manager will page to disk what is NOT immediately locked by other running processes in 4096k increments until sufficient memory is available for this NEW process coming into existence, &/or one that is demanding more RAM to do its work.
but the real bottom line is the whole idea of unlimited system memory (virtual memory) by way of useing the hardrive to augment real physical memory is outdated rubbish and not really valid on a modern machine..
It's not "unlimited", it is limited to the 4gb max memory addressability of 32-bit OS, & goes up in 64-bit ones.
That's where you're "off" man! Today's OS ARE VIRTUAL MEMORY BASED & ALL MEMORY TO THEM? IS VIRTUAL! Even RAM chip memory + pagefile.sys in total of them both.
Even IF you don't tell Windows to make a pagefile.sys? It will, a temporary one, that is subject to fragmentation of itself & yes, other files as it "grows/shrinks".
And, the very idea behind today's modern operating systems? IS Virtual memory use because to Windows? ALL MEMORY IS "VIRTUAL" AS FAR AS THE OS IS CONCERNED!
Which is exactly what you say is obsolete!
(the use of diskspace as memory (temporary swapped out/paged out in 4kb/4096kb increments of portions of programs &/or data that are NOT in use or locked)).
most younger folks.. those who belong to the cheap memory era and have never tried to run XP on 64 meg of ram or 95 on 16 megs have never seen swopfiling in action.. they read all this outdated junk about how to speed up their "virtual memory" and think it means something..
It does! Espcially what the post starter outlined... & the fact you are ALWAYS paging in today's VM using OS'... The technique he outlines avoids fragmentation of the pagefile.sys itself, generally, & other programs on disk with it, & it works.
In fact, this whole experiment & scenario I let you do above?
That is WHY I can see my system is faster (I rarely hear the HDD in fact, mechanical RAID 0 array here with a 128mb cache onboard it & managed by an onboard CPU on the RAID controller ontop of Windows diskcache OR what I use (SuperCache-II, better cache for NT-OS)) than normal ones using std. HDD bound diskdrives as a pagefile.sys location!
Off the SSD with my pagefile.sys on it? FAR FASTER ACCESS/SEEK to pagefile.sys interior data is why too.
Others not doing this "hit disk" which are 1000's of times (literally) slower than the SSD I use for my pagefile.sys location by far...
I.E.-> I page program data & resources in & out of it 1000's of times faster than most folks can & thus, see a performance diff. in the operation of Windows, especially in terms of Virtual Memory use & your Explorer.exe GUI shell? Probably the BEST EXAMPLE of a program constantly doing it... generating page faults (read/writes to pagefile.sys).
"It ALL boils down to how you use your rig, point-blank!"
it does.. u are perfectly correct..
Yes I am.
DO read this closely, & in its entirety.
The experiment above I noted for you to try?
That should illustrate to you the concept @ hand:
It WILL show you HOW paging is used & when (quite a lot, process by process in fact & that's what I will let you illustrate to yourself below using taskmgr.exe - explorer.exe your GUI shell? CONSTANTLY @ IT, paging data in & out of the pagefile.sys in fact as one example of how often you use your HDD pagefile.sys virtual memory area).
APK
P.S.=> It's pretty easy to see, if you do what I noted above as an experiment... but, moreso with an application like Photoshop, & even Windows itself if you bootup w/ out a pagefile.sys present (permanent one), & it WILL complain... & just end up forming a temporary pagefile.sys anyhow!
I think that will illustrate to you, for yourself to see, just how often you really ARE paging, & using VM on disk in pagefile.sys (page faulting WILL illustrate that to you, without question)... apk