Moonchild wrote:As for using 32-bit/64-bit alternatively: shouldn't be a problem at all. You'll probably get the compatibility check window indeed when you do that as the version identifier is different.
Okay, so maybe the question of which to use has an easy answer: install both, use the x64 one, and if you run into a compatibility issue or you run low on memory, just exit, run the 32-bit version, and History --> Restore Previous Session! [edit clarified "restore session"]
Moonchild wrote:Looking at commit charge isn't very useful when you want to know the actual memory use of a process - it merely states the maximum amount of memory (i.e. a limit) of the process' memory that may be committed to swap if needed. It doesn't say anything about your actual memory use.
Doesn't paging begin more or less when commit count exceeds physical memory? In any case, actual I/O to my pagefile on disk is what I'm trying to avoid. In theory paging out some not-actively-used memory is okay, but in practice I find it's hard to predict when you'll get to the point where you do see annoying responsiveness slowdowns.
If x64 PM uses 20-30% more memory than 32bit, is there any reason to doubt that at least some of that extra will be "actively" used?
BTW, I saw an interesting bit about memory usage of browsers; the Chrome developers say the "correct" measure is PrivateWS+(ShareableWS-SharedWS). Which equals totalWS-SharedWS. In other words, WorkingSet that *can* be shared with someone else (i.e. it's "shareable" rather than private) still counts unless it *is* in fact Shared with someone else! Unless of course that someone else is only another process of the same browser.
Chrome's about:memory shows the memory usage of any running browsers it recognizes (such as FF) -- too bad it doesn't recognize PM.
Apologies if I've strayed off-topic...
).