Linked by Thom Holwerda on Tue 14th Aug 2007 17:55 UTC, submitted by tudyparghel
"As we saw in part 1 of this series, large applications and games under Windows are getting incredibly close to hitting the 2GB barrier, the amount of virtual address space a traditional Win32 (32-bit) application can access. Once applications begin to hit these barriers, many of them will start acting up and/or crashing in unpredictable ways which makes resolving the problem even harder. Furthermore, as we saw in part 2, games are consuming greater amounts of address space under Windows Vista than Windows XP. This makes Vista less suitable for use with games when at the same time it will be the version of Windows that will see the computing industry through the transition to 64-bit operating systems becoming the new standard. Microsoft knew about the problem, but up until now we were unable to get further details on what was going on and why. As of today that has changed."
Permalink for comment 263542
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:
2005-07-20
This is why judging memory usage by what you see in the windows task manager is not the most useful thing to do. It can serve as a guide, but it is more than likely to be misinterpreted.
There's nothing wrong with using the task manager to determine how much memory is in use. You just have to be smarter than the screen you are looking at so that you have some idea what it means.
If you check under "Physical Memory", the place where it lists your physical memory size... you know, where you would think you are supposed to look... that usage number means nothing. It's a waste of space.
Commit Charge, however, tells you exactly what is going on.
XP says "Total Commit Charge 412MB"... that means that 412MB of memory are being used by "stuff", not caches.
Meanwhile, my stupid "Physical Memory" thing, the one on the top right, says "System Cache usage 728MB"... which means there's obviously a lot of caching going on for something... but the cached files don't show up in the commit charge, only memory that's doing something shows up there.
Now, yes, arguing over "Active memory usage" is pointless, since there are so many possible caching methods, Linux/BSD/Windows all do it completely differently, resulting in wildly different usage patterns for exactly the same thing.
Arguing over the total commit charge usage in various versions of windows is justifiable, however. That is not caching if it increases, it is plain and simple program bloat.
Yes, Free Memory may be wasted memory, from a caching perspective, but program bloat is wasted in a far worse way. You can't ever retrieve that waste.