Slashdot Mirror
Ars Analysis Calls Windows 7 Memory Usage Claims "Scaremongering"
Via newsycombinator comes a reaction at Ars Technica to the recently reported claims of excessive memory use on machines running Windows 7. From the article: "I installed the XPnet performance monitoring tool and waited for it to upload my data to see what it might be complaining about. The cause of the problem was immediately apparent. It's no secret that Windows 7, just like Windows Vista before it, includes aggressive disk caching. The SuperFetch technology causes Windows to preload certain data if the OS detects that it is used regularly, even if there is no specific need for it at any given moment. Though SuperFetch is a little less aggressive in Windows 7, it will still use a substantial amount of memory—but with an important proviso. The OS will only use memory for cache when there is no other demand for that memory."
More to the point, the company that wrote this little monitoring tool badly misunderstood basic principles of how the operating system works. At this point, I think we can move on and completely disregard any conclusion they came to. It either demonstrated profound ignorance or a deliberate attempt to mislead people it what turned out to be a slashvertisement of their products and company.
From the article:
One might almost think that this whole exercise was simply a cynical ploy. Allegations of Microsoft bloatware are, of course, nothing new, and oblique references to the old canard that what Intel gives, Microsoft takes away does nothing to dispel the impression that this is another case of Microsoft bashing.
What a surprise. Fortunately, people really didn't even let them get away with it even in the previous article. Microsoft deserves plenty of what slashdot slings its way, but let's stick try sticking to facts.
Irony: Agile development has too much intertia to be abandoned now.
It's not "hogging" memory if it dumps it the second you start up a program that needs it... It also doesn't make your system "appear" faster, it makes it faster. I paid for all that RAM, I don't mind it being taken advantage of; that's why it's there in the first place...
Windows 7 is sucking up your system memory to make Windows appear faster.
So windows has a feature which makes everything run faster and yet it only "makes Windows appear faster", instead of making it actually faster?
It seems to me that windows is only using hardware in a rather intelligent way: if it's not being otherwise used or needed, it uses it to boost performance.
Linux does the same thing, as far as I know, and you don't see anybody calling Linux a memory hogging OS.
Describing caching as a way Windows makes your computer "appear" faster is really a little disingenuous. If that is the only metric for your complaint then you should be angry that your processor caches as well. After all, your processor takes the time to check two or three caches every time it issues a move instruction. If it misses every time, then it has to pick what to throw out of the cache and read directly from memory. Wouldn't it be so much better if it just made a fetch to ram every time there was a move instruction? After all, your processors caches only "appear" to make your processor faster right? The question that people should be asking if they want to get upset about SuperFetch is does this approach to ram use benefit the user enough to be worth the extra complexity in the operating system's memory allocator.
if everyone is so afraid of their computer memory being used to the fullest, why do these people install so much of it?
I've got 8GB of ram in the machine I'm on at the moment, and I want the OS and applications to use it to the fullest and most efficient extent possible at all times. I didn't install a 64-bit OS and 8GB of ram so that I can see 6GB free at all times.
I want a new quote. One that won't spill. One that don't cost too much. Or come in a pill.
fflush() just flushes stdio's buffer, so that any data written to the file is sent to the operating system (via write() on *nix), making it visible to other programs. It does not flush anything in the operating system's own buffers/caches. Also, fclose() calls fflush() automatically, so calling both is redundant.
You're probably thinking of fsync(), a system call that does actually force data to disk. And should almost never be used, unless you enjoy waiting through several seconds of disk grinding and general unresponsiveness.
The vast, vast, vast, vast majority of that cached memory is read-only caches (like DLL caching and superfetch) which doesn't need to be "dumped". Some small, very small, portion of it is read/write disk cache, but that portion is never going to be dumped unless you're *completely* out of memory otherwise. And that's basically a "last resort failure mode" at that point.
You're as bad as the guys who wrote that article in the first place. If you don't know how Windows works, please don't talk about it.
Comment of the year
You have no idea what you're talking about. Superfetch is much more than stats on commonly opened files. It takes into account the times of the day, weekends etc. too among other advanced stats. Anyway if it's trivial to roll your own, why doesn't such a thing run by default in Ubuntu? That's the thing that's sad and depressing, not giving names to technology.
To state it again. This is not RAM memory you need, use or have purpose for. IF you do need it, it is zeroed-out and free'd to application in like 30ms (one frame in usual FPS games).
The problem with previous versions of windows (I haven't used anything newer than XP) is in how the OS decides that you do not "need, use or have a purpose for" certain types of memory.
The pathological, and yet all too common case with XP is the OS's decision that text pages should be dumped in favor of disk cache far too soon. The result being that if you have multiple apps open and a few that you haven't touched for roughly 10 minutes and then go to copy a couple of gigabytes of files around the text pages for those 'idle' applications are flushed out and the disk cache loaded with parts of those copied files (which you are unlikely to ever need). When you click on the iconbar to bring one of those formerly idle apps back to the foreground the system grinds away for a long time (obviously machine dependent but never instantly and frequently way beyond the point of annoying) as it reloads those text pages from disk before the application even starts to redraw itself much less starts becoming fully interactive again.
The worst part about that behavior is that, to the best of my knowledge, there are no knobs to tweak it. I can't specify how long a text page needs to be idle before it should be a candidate for flushing or even if it should be pinned down permanently so that is never paged out. I once went looking to see if there was a way to do it from within the application code itself - something like mlock()/mlockall() in posix - and I couldn't find an equivalent, which may just be a reflection of my own inexperience with the Windows API but I figured I would throw that out there anyway.
When information is power, privacy is freedom.
I didn't make a snide remark. I pointed out that windows maintains a pool of zeroed ram, and will constantly fill it when it's able to.
Windows will allocate from that pool first, and then top it back up when it hits a threshold of low free memory from supercache.
It then has the luxury of handling this in the background, so you're not waiting for the system to zero memory out, unless you somehow manage to totally max out the memory you've got in use.
It's at this point when you've got bigger problems, like the fact that the disk will probably become your bottleneck, not the speed at which you can zero out ram.
I didn't miss your point, I'm suggesting that you're not thinking like an operating system designer, and saying "how can i shorten the critical path of giving a process the memory it requests?" The answer is: Pre-zero memory, and fill the zeroed pool from the cache as needed when you get low. There's no "wait" for zeroed out memory, at this point.