Michelasso wrote:
1. If there is 3 times the difference in RAM used by the same application doing the same job in two different OSes I think I have the right to believe that such application is not optimized in the second OS. Not in terms of memory, at least.
Except that it isn't really the same app. The feature sets are different & they have been compiled for two different OS's with different memory management systems & with different API's. They don't even call the same routines to measure RAM use.
2. Yes, the physical pages that have been marked by the VM system as modified.
Why are all these pages marked as modified? Earlier you said, "Also considering that all web pages content in RAM are modified pages that will be swapped out when the free memory gets low." You still haven't explained what you mean by that, nor have you considered anything besides web page content.
3. Unless it is bugged, filling up the inactive memory, causing page outs that trash the system.
You are oversimplifing again. Don't forget that not everything in an inactive memory region has to be paged out -- if it has not been modified since being paged in, there is no reason to page it out before marking the region as free memory. As you (now) know, apps like Safari maintain cache files seperate & apart from the VM backing store. Since they are ordinary files, they are handled by the vnode pager, not the default pager, just like code. So even hard faults don't necessarily cause page outs. Understand?
The tools we have available give a valid idea about what's going on in the systems. More "top" than AM, anyway. And vm_stat. 1 second granularity is more than sufficient for a fast analysis.
You misunderstand what I mean by granularity. You still seem to have the idea that all objects in memory are large, for instance that web pages are made up not of many different smaller parts that each load separately but of one big thing that either is or isn't in memory at any given time & it takes substantial time to load if it isn't. That isn't true. It is the same for code segments -- much of it is quite small & it takes very little time for the vnode pager to load it into memory. Study Safari's Activity window & vmmap's output & you should see that this is true.
Because of this, a 1 second sample rate will miss much of what is going on -- thousands of memory changes could occur in that interval. In fact, overview tools like AM or top only loosely approximate memory use because an accurate analysis takes considerable system resources. (See for example the "PERFORMANCE vs. ACCURACY" section of the top man page.)
For AM's per process memory statistics it is even worse. If you have used vmmap (which to get accurate numbers walks through each page, checks its pmap entries, & so on), you probably have noticed that it can take as much as a second or two just to compile statistics for one process. Now imaging how much time it would take AM to do the same for all the processes it displays. Obviously, AM does not do this. (If it did, AM would show its own use of CPU time soaring).
AM makes no attempt to sort out what is in the memory space of a process, what put it there, or its purpose. In fact, it doesn't even try to estimate the use of active, inactive, or wired memory on a per process basis, which is part of the reason you can't get the per process memory numbers it shows to add up to the totals AM shows for all processes.
So what you call a "fast analysis" is in reality a guess based on knowing only a small part of what is really going on, some of it an estimate, & most of it on what you admit is hard to understand & confusing. And yet, even after you have read through Apple's doumentation explaining in detail what is needed for a real analysis, you ignore that, in part because it is "too detailed."
