I've noticed that a pretty big chunk of my ram has been sucked away because of system cache and I didn't think much of it until I just installed 1GB of ram and noticed now that 250MB of ram are being sucked away because of system cache. What is system cache and how can I limit it? Because I have systems with 384Mb of ram and probably use 64MB of system cache and run fine so why do I need all of a sudden 250MB of system cache?
System cache windows xp
- Thread starter imported_goku
- Start date
Windows is a modern OS with a modern memory management scheme; let it manage that. In a nutshell, RAM that's sitting around doing nothing is wasted RAM, so Windows will put any that it thinks it might need into use. You're seeing the result of that.
Long ago people used to argue about an OS that allocated RAM to system tasks when the RAM otherwise wouldn't have been in use. The people thought that was wasteful. They didn't realize that RAM sitting around doing nothing is itself wasteful - the RAM is wasted doing nothing when it could be put to other use.
If you'd like, you can uninstall any services and similar features you don't need, but I wouldn't worry about it....
System cache is RAM that the OS has either set aside for quickly allocated use or RAM that it is just using for the sake of not wasting it. You probably already have it running on small cache, like most users. Servers and databases will actually use the Large Cache Option, which will page just about everything (and load the kernel into memory, I believe) for use.
Other numbers you should look at are the ones under 'Commit Charge'. They tell you how much memory (virtual memory included) is being used, how much is available, and what was the peak of usage. If the peak is getting too close to the max (or exceeding it), you either need more memory or you need to clean up the system of background tasks.
Other numbers you should look at are the ones under 'Commit Charge'. They tell you how much memory (virtual memory included) is being used, how much is available, and what was the peak of usage. If the peak is getting too close to the max (or exceeding it), you either need more memory or you need to clean up the system of background tasks.
Nothinman
Elite Member
- Sep 14, 2001
- 30,672
- 0
- 0
LargeSystemCache favors disk cache over running applications, if you enabled that you deserve whatever you get.
Actually 'Commit Charge' is the total amount of physical memory being used, Virtual Memory can never be measured accurately because there's 2G available for every process and lots of things like memory mapped executable and libraries are mapped into multiple processes address spaces, so they only use 1 chunk of memory but are available to any number of processes. Page file usage is also inaccurate in task manager because it includes reservations in it's numbers, the only way to get an accurate reading is by using perfmon.
Actually 'Commit Charge' is the total amount of physical memory being used, Virtual Memory can never be measured accurately because there's 2G available for every process and lots of things like memory mapped executable and libraries are mapped into multiple processes address spaces, so they only use 1 chunk of memory but are available to any number of processes. Page file usage is also inaccurate in task manager because it includes reservations in it's numbers, the only way to get an accurate reading is by using perfmon.
Just a minor, nitpicking tweak: 'Commit Charge' is *almost* but technically not quite the entire amount of physical memory in use, because the kernel's nonpaged pool doesn't count (it will never be written to the pagefile) but it is certainly using physical memory. Commit Charge is the amount of paged memory that would need to be written to disk if everything on the system were to be paged to disk immediately. On my system, my kernel's nonpaged pool is about 23 MB, so depending on how much physical memory you have, it may or may not be significant.
For those interested, Commit Charge is only really useful as an indication of how large your pagefile should be (and it's not even very good at that). Many people like to have a paging file that is just big enough to handle their typical "peak commit charge" (available in the performance tab of task manager), so that a single poorly written leaky app can use up all of the physical memory on a system but will not trigger an "out of virtual memory" error with their typical app load.
It is true, however, that if your commit charge ever goes above the amount of physical memory available to your system (which on many systems is less than the RAM you have because of video ram sharing and bios shadowing), the remaining amount must be paged out to disk. So at any current moment, you MUST have a pagefile of adequate size to hold ( Commit Charge - Physical Memory Available ) bytes. Otherwise, you would hit "out of virtual memory" errors and likely would be unable to create processes, threads, handles, and other kernel objects necessary for most apps to function, rendering your system unusable. Task manager is just about the only way to salvage such situations because you can't even launch a utility designed to kill processes or find leaks...
Yes but like I said, I dont understand why windows need more and more ram as I increase the amount of ram I have. It seems like its going by a multiple. Also this is a problem because I noticed that when programs start eating away at the ram and there is not more left, the system cache still stays the same. I do I limit windows from continuously eating more ram as I put it more. 65MB is fine and is what I had before when I had little ram and windows ran perfectly fine. Seems to me windows just feels like "filling up the space".
Whoops, I forgot to mention that "physical memory available" in MY usage above is NOT the same as physical memory available in Task Manager.
In task manager, physical memory available is the tally of pages in the Zeroed, Free, and Standby lists in the kernel's memory manager. So it represents what is "immediately available" for applications to start using. Apps can always request more than this amount, but pages of memory from other apps or the system will need to be written to disk before the memory will be available, slowing down the system. What is interesting is that the "Standby list" actually contains some pages that are considered part of the system cache (they have already been flushed to disk so they're just lingering), so that memory is reported twice: in the "Physical Memory Available" AND the "System Cache" amounts. That is why if you add up the cache, available, and kernel used memory you sometimes calculate a number higher than the total physical memory on your system.
When I used the term "physical memory available" in my post above, I meant "available to the kernel at system boot". If your system, for instance, has 128 megabytes of RAM but 8 megabytes of shared video memory and 1 MB of BIOS shadowing, you will only actually have a total of 119 MB of physical memory available for use by anything on your system (kernel, apps, cache, etc). This should be reported accurately by the Physical Memory Total amount in Task Manager.
There are sometimes multiple definitions of these quantities, and it always helps to be as explicit as possible when bandying these terms about...
In task manager, physical memory available is the tally of pages in the Zeroed, Free, and Standby lists in the kernel's memory manager. So it represents what is "immediately available" for applications to start using. Apps can always request more than this amount, but pages of memory from other apps or the system will need to be written to disk before the memory will be available, slowing down the system. What is interesting is that the "Standby list" actually contains some pages that are considered part of the system cache (they have already been flushed to disk so they're just lingering), so that memory is reported twice: in the "Physical Memory Available" AND the "System Cache" amounts. That is why if you add up the cache, available, and kernel used memory you sometimes calculate a number higher than the total physical memory on your system.
When I used the term "physical memory available" in my post above, I meant "available to the kernel at system boot". If your system, for instance, has 128 megabytes of RAM but 8 megabytes of shared video memory and 1 MB of BIOS shadowing, you will only actually have a total of 119 MB of physical memory available for use by anything on your system (kernel, apps, cache, etc). This should be reported accurately by the Physical Memory Total amount in Task Manager.
There are sometimes multiple definitions of these quantities, and it always helps to be as explicit as possible when bandying these terms about...
Hehe. Sorry goku, I'm kinda getting a kick out of this. I know your goal is to get the system to run faster.
The objective you are trying to achieve:
Reduce the amount of memory in use so that your system has more memory to work with.
How you are going about it:
Reducing the amount of memory your system has to work with so that it will have less in use.
You are right though: Windows is kinda "filling up the space". It's seeing you have a bunch of memory that's not being used so it's using it for cache to speed up your system. Remember, your apps are also dependent on the OS for performance. It does no good to have a speedy app with lots of spare memory if that app is snoozing while it waits on the OS to complete some request it sent.
Hope this helps.
The objective you are trying to achieve:
Reduce the amount of memory in use so that your system has more memory to work with.
How you are going about it:
Reducing the amount of memory your system has to work with so that it will have less in use.
You are right though: Windows is kinda "filling up the space". It's seeing you have a bunch of memory that's not being used so it's using it for cache to speed up your system. Remember, your apps are also dependent on the OS for performance. It does no good to have a speedy app with lots of spare memory if that app is snoozing while it waits on the OS to complete some request it sent.
Hope this helps.
It doesn't *need* more RAM... it is using the RAM you have available more efficiently.
You seem to have a misconception about the way the system cache manager works in Windows, and how its size is reported in Task Manager.
There are effectively TWO components that comprise the "System Cache" size that task manager is reporting to you: Standby memory and Mapped file memory.
Standby memory represents memory that happens to have valid file cache data, but that data has already been written back to disk and therefore the memory can be reclaimed instantly by the memory manager and used for any purpose whatsoever (including handing it to apps). My system, for which Task Manager reports as having 420 megabytes of "System Cache", currently has 256 megabytes of memory in the "standby" state. I.e., more than half. You can see this in the kernel debugger, if you so dare.
Mapped file memory, on the other hand, is memory that the System process (in the context of its cache manager thread) has set aside (and can relinquish as conditions suggest) to perform behind-the-scenes file-level caching of any file opened by any process on the system. Files are mapped into the System process and paged in on demand as requested by the NT I/O subsystem (NtReadFile, NtWriteFile, etc). So even if you have no clue what mapped file I/O is or why it's beneficial, the system happens to do it for you behind the scenes for the purposes of caching. According to the kernel debugger, my system is currently using 182 megabytes for this purpose, and it has it completely filled with useful stuff like keeping ntoskernel.exe in memory, plus the code of several device drivers, several opened data files, as well as portions of the system registry (all of which are accessed more than you probably think).
So you're probably asking all this because you want to keep as much memory free for your apps to fill up as possible. Well, as I just pointed out, "Standby Memory" which makes up a sizable chunk of the System Cache *is* readily available to your apps. The rest of the System Cache (mapped file data) is ALSO available to your apps, but it must first be paged out to disk before it can be used.
If your apps start using more physical memory than is available on your system, the Cache Manager recognizes this situation and scales back the size of the Memory Mapped cache accordingly. The cache manager doesn't have to scale back the size of the Standby List at all becaue the memory manager handles that as appropriate (treats it as free memory).
You can view all of this in Perfmon if you play with it for a while. The Win2k resource kit came with an app called "Leakyapp.exe" that was very useful for demonstrating how apps that take up lots of virtual memory can cause your system to start paging stuff to disk, and how the cache manager responds, and how the paging file can grow, etc.
You're very welcome. I apologize if I came across like a know-it-all trying to show off. I certainly don't know it all
I just happen to know a lot about the Windows NT Memory Manager, so I thought I'd chime in. Some folks might find it interesting. But most probably just don't care. And why should they?
Then why doesnt windows fill it up completly if most of the space is "standby space"? I dont want to have to wait for my program to first use virtual memory and THEN windows decides it really DOESNT need all that ram then gives it up.
It's not the kernel part of memory utilized or useful processes utilizing memory I dont understand, its the fact that windows has this "standby memory".
Smilin, its ok for windows to use up to 50MB (excluding critical processes and Kernel) but past 50MB I really don't need windows to suck up more ram because it thinks it will speed up things. At one point my machine had 384MB of ram now it has 1GB, despite the fact that windows now knows theres more ram available and it's now utilizing it, it still doesnt speed up the system. My system runs just as fast with 384MB of ram as it does with 1GB, the only reason why I have 1Gb is because I use applications that can take advantage of 1GB, windows cant! It seems like there is really no reason to have this standby memory because technically all the ram is "standby memory".
Is there a way I can reduce the "standby" portion of the system cache?
It's not the kernel part of memory utilized or useful processes utilizing memory I dont understand, its the fact that windows has this "standby memory".
Smilin, its ok for windows to use up to 50MB (excluding critical processes and Kernel) but past 50MB I really don't need windows to suck up more ram because it thinks it will speed up things. At one point my machine had 384MB of ram now it has 1GB, despite the fact that windows now knows theres more ram available and it's now utilizing it, it still doesnt speed up the system. My system runs just as fast with 384MB of ram as it does with 1GB, the only reason why I have 1Gb is because I use applications that can take advantage of 1GB, windows cant! It seems like there is really no reason to have this standby memory because technically all the ram is "standby memory".
Is there a way I can reduce the "standby" portion of the system cache?
Nothinman
Elite Member
- Sep 14, 2001
- 30,672
- 0
- 0
If you mean physical memory, it does.
Virtual Memory is always in use, if you mean the pagefile then Windows _should_ use memory that's designated as cache and not dirty before pushing a lot of things to the pagefile. But I'm not very versed in how exactly NT balances that, it's a tricky thing to get right because noone's every happy and everyone thinks they know everything about VM tuning...
So you want the OS to have to issue reads to the hard disk everytime a read is needed instead of doing read-ahead and caching the results. Do you know what kind of slow-downs this would create? I would bet that just application start times would atleast double because of all the paging in of executable and shared library data.
That says to me that you weren't memory bound before.
It seems that you don't understand what the standby memory really is.
Goku, another thing that you're not realizing that might be causing you confusion:
For your apps the memory used has to stay in use until the app is done or it's written to disk (by the app or paging).
For your OS, there is some memory in this same situation. However, the "excessive" memory you are seeing is optional. It's being used for cache to save you disk access and whatnot, but if an app needs it, it gets it. Again, it's "optional" it can be discarded instantly if needed elsewhere. It's only being used to optimize performance and can be reduced at any time without having to write it out somewhere first.
I would like to encourage you to go google some of this or search anandtech. It's not a new topic and you're not the first person to ask this. Someone may be able to further optimize window's memory management but I guarantee it won't be you or me
For your apps the memory used has to stay in use until the app is done or it's written to disk (by the app or paging).
For your OS, there is some memory in this same situation. However, the "excessive" memory you are seeing is optional. It's being used for cache to save you disk access and whatnot, but if an app needs it, it gets it. Again, it's "optional" it can be discarded instantly if needed elsewhere. It's only being used to optimize performance and can be reduced at any time without having to write it out somewhere first.
I would like to encourage you to go google some of this or search anandtech. It's not a new topic and you're not the first person to ask this. Someone may be able to further optimize window's memory management but I guarantee it won't be you or me
You don't want to reduce it: it's considered "free" memory. When your app wants a page, the memory manager has to figure out which page to give to your app.
This page can come from four different places (in this order):
1) The "Zeroed" list. This memory is literally doing nothing, and contains no data whatsoever. It has been overwritten with zeroes by the Zero Page thread so that processes can't read each other's memory. It is the MOST readily available memory in that the system literally does no work to hand it to the requesting app.
^^^
2) The "Free" list. This memory has been recently deallocated, so it is doing nothing whatsoever and contains invalid data. However, the Zero Page thread hasn't had a chance to overwrite it with zeroes yet. As such, it is considered a "security risk" until it has been zeroed. If The memory manager first must zero the page before it can hand such a page to a requesting app. Periodically the zero page thread wakes up and zeroes some of these pages, moving them to the "Zeroed list."
^^^
3) The "Standby" list. This memory is not needed by any process, but may still contain valid file cache data that has already been written back to disk (or was never dirtied to begin with). The reason pages in this list have not yet been moved to the Free list is that it is not necessary to do so: keeping them around longer means that we might get a file cache hit! Pages at the head of this list are the first to be used by the memory manager when the Zeroed and Free lists are empty. But if the zeroed and free lists are not empty, memory will remain in the standby state as long as possible. To give a page on this list to a requesting app, the memory manager only needs to zero it out, EXACTLY like the Free list. (Why zero out perfectly good cached data when zeroing is relatively cheap?)
^^^
4) The "Modified Page" list. Pages on this list are all dirty and must be written to disk via the "modified page writer" in the System process. This list contains either file cache data that needs to be flushed to disk, or dirty pages from an application that the system has determined must reduce its working set to free up pages for dwindling Standby, Free, and Zeroed lists. Once the modified page writer has written a page from this list to disk, the page is immediately moved to the "Standby List." Note that ALL dirty file cache pages go into this list, but only some dirty app working set pages go into this list (as demand requires).
I know there are a lot of details here, but does it make any more sense now?
Standby memory *is* free memory, and is treated as such by the memory manager.
About the memory bound thing, I was never memory bound with 384MB of ram, I just wanted more because I am using premiere and I have noticed the farcry has been getting really bitchy at times because it doesn't like being restricted to so little memory. About the standby memory, it *SEEMS* to me that standby memory is a *Buffer* between the ram and HDD but if it is a *BUFFER* I still dont under stand why such a large buffer, 50MB is plenty big enough buffer right? Oh apparently this is a big enough problem that companies have actually released programs to PREVENT windows from using too much system cache. I think it's called "O&O CleverCache". Please let me know what I said IS correct. Thanks!
Oh wait I just realized somin, when I go to task manager and see that my system cache is 300MB it looks like it's all the memory that is in use at the moment but when I use Rambooster and try to free up 1Gb I see the system cache shrink to 33MB and after it's done it stays! Now this would seem good in my situation since I hate wasted memory but the problem is there is still 200MB+ being used despite the fact I have like nothing running, so now I see the commit charge and as stated earlier commit charge is practically all the physical memory in use but what Im wondering is why is my commit charge so HUGE when nothing is running!? Like I have hardly any background programs running and services too!
Rambooster (and almost every program like it) is a JOKE. It allocates lots of virtual memory and exits. This forces the Windows memory manager to page out to disk anything that was in memory doing something useful, giving you the illusion that you suddenly have more memory available.
But you have just slowed your system down unnecessarily. Every time your system context switches to another process, every instruction executed and every bit of data accessed will IMMEDIATELY trigger a page fault (disk access). You may think, "That's not a problem for me, I have nothing running." I guarantee that you have at least 15 processes and a total of more than 100 threads running, whether you have any open apps or not. All of these system processes and threads run periodically (accessing memory, opening files, reading the registry, etc) whether you like it or not. Starving them of physical memory by forcing them (and their cached files) to be paged to disk with "Rambooster" is entirely counter-intuitive.
Your Commit Charge is still the same after "Rambooster" ran because all you have done is force the transfer of committed pages in physical memory to pages written to your pagefile on disk. Commit Charge is the size of the paging file required to store all committed pages on the system to the pagefile. Whether these pages are in physical memory or already in the pagefile is irrelevant: commit charge is the same.
See, by using Rambooster you have not changed the amount of memory in use one bit, whatsoever. You have neither boosted the amount of RAM physically available to your system, nor the amount of physical RAM necessary to run your system. In fact, you have boosted nothing except page file usage!
The moral of the story is: let Windows figure out when to page out stuff to the pagefile. Don't try to manually do it with a hack program like Rambooster. All you will do is take useful pages out of memory and put them into the page file, where they will only need to be read back from disk a few moments later.
Nothinman
Elite Member
- Sep 14, 2001
- 30,672
- 0
- 0
When you have a 200G drive with data on it, you can never have too much buffer memory. Standby memory can be given to an application in a few cycles (however long it takes to zero the pages and change the pagetables for the affected processes) so there's on real benefit in limiting it, but there is a benefit in using it for caching because a read from the hard disk takes many times longer than it does to read from memory or update a PTE. By limiting your system cache to 50M or whatever you basically waste all the other memory not currently used by applications because it's sitting there idle doing absolutely nothing when it could be used as system cache.
Companies write applications because people will buy them whether there's a real problem or not. There's no benefit from palm readings either, but people pay for them too.
Think about it this way:
Why did you buy ram? To make your computer faster...
How does it make it faster? By using it OR not using it?
By using it, of course. Unused RAM is wasted RAM. You WANT the OS to page as much usefull information into RAM as possible, every meg wasted is another meg you have to dredge up from the harddisk at a huge penalty to performance.
The trick is that you need USEFULL information up in RAM. Back in Win98 days when memory leaks ruled the world as your RAM filled up everything got slower, not because of cache or anything but because Win9x had the most god-awfull memory management sceme imaginable.
The NT platform was much smarter at this sort of thing (and linux/bsds are now smarter since WinXP/W2k is getting long in the tooth.) so you want it to use up your ram to boost performance.
If you getting a performance penalty by the system using cache it's from bad memory management design in the OS itself and adding on some crappy POS software isnt' going to help any.
why memory optimizers are a hoax
Why did you buy ram? To make your computer faster...
How does it make it faster? By using it OR not using it?
By using it, of course. Unused RAM is wasted RAM. You WANT the OS to page as much usefull information into RAM as possible, every meg wasted is another meg you have to dredge up from the harddisk at a huge penalty to performance.
The trick is that you need USEFULL information up in RAM. Back in Win98 days when memory leaks ruled the world as your RAM filled up everything got slower, not because of cache or anything but because Win9x had the most god-awfull memory management sceme imaginable.
The NT platform was much smarter at this sort of thing (and linux/bsds are now smarter since WinXP/W2k is getting long in the tooth.) so you want it to use up your ram to boost performance.
If you getting a performance penalty by the system using cache it's from bad memory management design in the OS itself and adding on some crappy POS software isnt' going to help any.
why memory optimizers are a hoax
I dont know, I would partly have to disagree with you guys with "memory" optimizers. I know for a fact that memory optimizers create redundant information to "fill up the ram" which in turn shoves parts of programs into the page file which can be useful some times on systems with low ram and inactive processes.
For example I am running Simcity 4 and I want it to run as fast as possible, so by using the program and forcing all the inactive processes into the page file I now have a great deal of physical ram just for Simcity4. Because had I not used rambooster, most of Simcity would have been paged resulting in poor performance which I have observed in previous instances. Rambooster essentially makes it's self really big which in turn shoves everything into the pagefile and since Simcity4 is pretty conservative, it would normally have just gone into page file. I never run rambooster on powerful systems with lots of ram because I've never really had problems with lack of ram (Only in extreme cases). Also I actually used Rambooster back in the days on Windows 98, I had never knew why I needed to "clear up ram" after a while so I just used the program, now in the 2000/XP environment when I first used it I never encountered these issues and didnt think much of it. So the only time I "really" use rambooster is on my PIII 600MHZ 256MB ram Windows 2000 laptop when I want to play simcity4. I first close practically every process running which includes explorer and then run simcity 4 from taskmanagers run dialogue.
Oh Nothinman, you made a very good point about companies who write applications with no real purpose, just like palm readings. Never really thought of that!
For example I am running Simcity 4 and I want it to run as fast as possible, so by using the program and forcing all the inactive processes into the page file I now have a great deal of physical ram just for Simcity4. Because had I not used rambooster, most of Simcity would have been paged resulting in poor performance which I have observed in previous instances. Rambooster essentially makes it's self really big which in turn shoves everything into the pagefile and since Simcity4 is pretty conservative, it would normally have just gone into page file. I never run rambooster on powerful systems with lots of ram because I've never really had problems with lack of ram (Only in extreme cases). Also I actually used Rambooster back in the days on Windows 98, I had never knew why I needed to "clear up ram" after a while so I just used the program, now in the 2000/XP environment when I first used it I never encountered these issues and didnt think much of it. So the only time I "really" use rambooster is on my PIII 600MHZ 256MB ram Windows 2000 laptop when I want to play simcity4. I first close practically every process running which includes explorer and then run simcity 4 from taskmanagers run dialogue.
Oh Nothinman, you made a very good point about companies who write applications with no real purpose, just like palm readings. Never really thought of that!
That's a great article, Drag. You frequently come up with some great reads.
I gotta say reading through some of the comments afterwards really cracked me up. Bunch of wannabees trying to discredit Mark Russinovich. HA! There was some guy in there ranting about his MCSE, MCSA, CNE yada yada and talking bout the Technet articles he could quote. Funny part is that every one of the guys (as far as I know) that WRITE the technet articles have a copy of Mark's "orange" book sitting on their shelves.
FYI guys, you've all combined written half a book by now and I don't think goku is going to get it. Give him a "memory optimizer" and send him on his blissful way.
Sim doesn't say anything to the system about the RAM. Or at least it shouldn't.
And it helps if you get the terms right when discusing this sort of things. Virtual memory isn't disk swap file. A disk swap is disk swap. I know that MS mixes the terms up a lot but...
Virtual memory is the amount of ram that system's programs percieve. That's always going to be 4 gigabytes on a 32bit x86 system. That's virtual ram, it's done that way so that games and programs don't have to worry that much about memory and they let the OS take care of the details.
This is one of those advancements put out by IBM back in the day. Let the OS manage memory, the programs don't have to worry about it and they don't have to second guess continiously what other programs are going to use.
And it helps if you get the terms right when discusing this sort of things. Virtual memory isn't disk swap file. A disk swap is disk swap. I know that MS mixes the terms up a lot but...
Virtual memory is the amount of ram that system's programs percieve. That's always going to be 4 gigabytes on a 32bit x86 system. That's virtual ram, it's done that way so that games and programs don't have to worry that much about memory and they let the OS take care of the details.
This is one of those advancements put out by IBM back in the day. Let the OS manage memory, the programs don't have to worry about it and they don't have to second guess continiously what other programs are going to use.
Nothinman
Elite Member
- Sep 14, 2001
- 30,672
- 0
- 0
Who are "they" that are putting things into your memory? Disk cache uses memory but it's essentially free for applications, it doesn't 'push' anything to the pagefile and it is freed almost instantaneously in the case that it's needed by an application. SimCity 4's map is in main memory and it's probably in the disk cache in the first place because of read-ahead that the OS does to speed up disk reads. When SimCity starts up and reads the beginning of the map file the OS will also schedule the read to include more of the file (not sure of the numbers for NT) so that if the process tries to read the same file again, and the chances are good that it will, the data will already be in memory and we'll save time by not needing an extremely slow disk read.
And frankly the fact that you use the term Virtual Memory to refer to the pagefile shows that you don't really understand how the system works.
Exactly, which causes things to get pushed into the pagefile that normally wouldn't have needed to go there. So you essentially create slow downs in the long term because 5 minutes after you run Rambooster the OS has to page back in things like explorer or your game that normally would have never needed to be evacutated from memory.
Essentially SimCity has no say what happens to it. If the OS decides if it's time to evict something from memory, this isn't DOS or Win9X any more.
Rambooster is a sugar pill, please read up on how VM works before going on here again.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 19K
-
-
-
Facebook
Twitter