Re: real verses Virtual memory
Re: real verses Virtual memory
- Subject: Re: real verses Virtual memory
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 10 Oct 2009 10:03:43 -0700
On Oct 10, 2009, at 9:53 AM, jon wrote:
Ok, let me re-word it then, is there a way i can keep a process
from using Disk writes as a form of it's own memory use?.... I
already know that it is a memory "thing" since the program never
uses the disk to write out any files. (during the process)... nor
use the disk in any other way, except for the memory being "virtual".
there are no files being accessed, only the webView.... that is
it's source of data.... it's only source. it works on that data,
finishes, and does nothing for 20 more seconds. (a trigger can
happen, but even if there was no trigger, the disk writes are
there)
If there are reads and writes being caused by such a process, it could
be because of several reasons:
1) as the app is launched, the executables (app and frameworks) and
data files will be read from the filesystem (but not necessarily off
disk)
2) if there is a persistent cache -- a web cache, perhaps? -- it may
be updated, causing I/O
3a) if the system is under memory pressure, allocations may cause
other applications to page out memory
3b) if memory pressure & there are other active applications, your app
may page out / in memory
4) your code may be indirectly triggering other disk I/O events via
the APIs it calls
(1) is normal and there isn't anything you can do about it (other than
not relaunch your app all the time -- maybe a daemon instead?).
However, on a system that isn't under memory pressure, all of the
executable gunk will be in cache -- in memory -- after the first
launch and subsequent launches won't hit the disk.
(2) is, again, normal and the default behavior. Depending on your
needs, you might want to turn off the caches used by the URL loading
subsystem. And, if possible, use a HEAD request to determine if the
remote content has changed before pulling it all down with a GET or
POST.
(3a/b) Not much you can do here beyond minimizing your app's memory use.
(4) Use Instrument's file I/O instruments to determine what is
triggering I/O. Then figure out if you can eliminate it.
In other words: No, there isn't a way for your app to use "real
memory". Or, to rephrase, there isn't a way -- at least, not a polite
way -- to guarantee that your app is going to have a certain amount of
physical RAM allocated to it. Since there is no way for your app to
know what demands may be made by other applications, there is no way
for you to reserve memory resources without potentially grossly
negatively impacting the performance of some other application. The
system goes to great lengths to dole out resources efficiently and it
is best to let it do its job as best it can.
b.bum
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden