Re: Memory Warnings
Re: Memory Warnings
- Subject: Re: Memory Warnings
- From: Quincey Morris <email@hidden>
- Date: Wed, 08 Oct 2014 06:42:46 +0000
(reposted after editing for length)
On Oct 7, 2014, at 22:12 , Gerriet M. Denkmann <email@hidden> wrote:
> Is there a way for the app to find out how much memory it is currently using?
Here’s my take on this, which may be way off base:
There’s really no practical way to answer such questions any more. The way memory is managed is so varied, so diffused that even if you could get an answer, it would be as likely to lead you astray as to help you.
In practice, I think the question is not how much memory your app is using, but how fast your memory use is increasing over time.
If it’s not increasing over time — and I’m speaking in the most general way possible here, so using more memory per opened document isn’t what I’d call increasing over time, in this context — then you have a fairly easy evaluation. Your app fits (in the foreground) or it crashes. Your app retreats gracefully (to the background) or it’s terminated.
The way we program now, we generally regard increasing memory use over time as a memory leak, and we fix our code so this doesn’t happen and usage is stable. So, it fits or it crashes.
> When I have a file of 100 KB and do:
> myData = [NSData dataWithContentsOfFile:options:error: ];
> myBytes = myData.bytes;
> how much Ram am I now using? 100 KB or 200 KB? I.e. does "bytes" just return a pointer to some internal structure in NSData?
>
> Would options = NSDataReadingMappedIfSafe be of some help?
The general answer is that you don’t know how much it’s using. In practice, the answer used to be 100KB (“bytes” returned an interior pointer). But this isn’t always true any more. GCD data blocks, which can be bridged to NSData, can come in pieces, and in that case “bytes” may copy the data into contiguous memory.
Mapped data might help in common cases, but how does this save you from “it fits or it crashes” when the file turns out to be on a non-local file system, on which mapping doesn’t work? Memory mapping is more about performance than size, perhaps.
> static dispatch_once_t justOnce;
> dispatch_once( & justOnce, ^{ _myData = [NSData dataWithContentsOfFile:options:error: ]; } );
> If I would (upon receiving a memory warning) release myData, I would never be able to get it back, would I?
>
> How could I handle this case?
Given that ‘dispatch_once’ is intended to do something only once, it’s hardly a shock that it doesn’t help in this case. Anyway, the problem is not in keeping a single but discardable copy of the data, it’s in making the discard/recovery process thread safe.
You can easily use a construct like GCD semaphores to ensure the integrity of the data recovery after discarding, but you have to be careful to avoid deadlocks. Or, you can easily use a construct like GCD serial queues (perhaps even the main queue) as a deadlock-free of getting to the same result, but you might have to redesign your code for asynchronicity with regard to the queuing.
Once you’re in the deeps of thread safety, I’m pretty sure there are no more free lunches.
_______________________________________________
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