Re: Application memory sizes
Re: Application memory sizes
- Subject: Re: Application memory sizes
- From: Greg Titus <email@hidden>
- Date: Sun, 7 Oct 2001 12:45:11 -0700
On Sunday, October 7, 2001, at 12:07 PM, Finlay Dobbie wrote:
On Sunday, October 7, 2001, at 07:49 pm, Simon Wright wrote:
I consider my app to be a _very_ modest one and I am puzzled by these
numbers. Does the Resident number really mean that my app is taking 12
Megabytes? The percentage memory shown in the Process Listing seems to
bear this out. What's more puzzling is the Virtual number - what could
possibly cause my app to show 254 Megabytes here? Is there some PB
setting that I've overlooked?
The shared memory is mostly frameworks and things that are loaded once
and shared across the entire system of applications. Cocoa depends on
lots of other frameworks which all have to be loaded. 12MB sounds
roughly OK, expecially when you consider that all your windows are
double-buffered and probably use exorbitant amounts of RAM :-)
Finlay is right, but I think his answer deserves a little more
explanation...
The resident and virtual numbers for your app is all memory that is
'mapped' by your application, including memory which may be shared with
any other process on the system. The memory used by the instructions in
the frameworks is shared among all applications using those frameworks.
In the process listing it will look like each app is using a ton of
memory for this, but in fact, it is only in RAM once (at most). Most of
it isn't in RAM at all at any particular moment, but address space is
reserved for it in case your app calls that code and it needs to be
executed (this is the virtual number). Code can be loaded out of the
executable / shared library file on the disk as needed and then
discarded later to be loaded again as needed, so the virtual number in
the process listing doesn't represent space used in the swap file
either. (Code - and other memory mapped files - can be 'swapped' back to
the original location it was loaded from.)
Your window backing store is also shared between your process (which
does the drawing on it) and the Window Server process (which flushes the
buffer to the screen). This is another instance where the process
listing will 'count' the same memory twice. A single full-screen window
on a 1600x1200 millions of colors display will take nearly 2 megabytes
of backing store, so this can add up pretty fast.
So, in short, don't worry too much about these numbers. It's almost all
frameworks and window backing store and there isn't much you can do
about it in your particular app. What you need to worry about is if
these numbers tend to rise over time as you use your application (i.e.
you have memory leaks). Any amounts over the startup numbers are usually
non-shared memory and thus have a much greater impact.
Hope this helps,
-Greg