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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to