Re: Memory Warnings
Re: Memory Warnings
- Subject: Re: Memory Warnings
- From: David Duncan <email@hidden>
- Date: Wed, 08 Oct 2014 09:10:54 -0700
Once your application is in the background it becomes fair game for being terminated. So even if you're using a very reasonable mount of RAM, if you're in the background you can expect that if some other application needs the memory your application will be terminated.
--
David Duncan @ My iPhone
> On Oct 8, 2014, at 2:06 AM, Gerriet M. Denkmann <email@hidden> wrote:
>
>
>> On 8 Oct 2014, at 13:42, Quincey Morris <email@hidden> wrote:
>>
>> (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
> It's not. Checked also with Leaks Instrument.
>> ― 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.
> It runs in the foreground. But when in background it sometimes gets terminated.
>
>>
>>> 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.
>
> I made a small iOS app which has just 3 buttons:
> Data (loads NSData from file, which resides in the app bundle)
> Bytes (which uses myData.bytes)
> Count (which sums all bytes in myData)
>
> Result with NSDataReadingMappedIfSafe, Persistent Bytes in Instruments, Allocations:
> No change with any button (always ca. 3.5 MB).
> Data button takes 1 msec, Bytes 73 μsec, first Count takes 250 msec longer than subsequent Counts.
>
> Without NSDataReadingMappedIfSafe:
> Data button increases Ram use by 15 MB (about size of file); takes 250 msec.
> Bytes, Count: no change. Bytes takes 13 μsec. All Counts take same time (ca. 50 msec).
>
> So NSDataReadingMappedIfSafe seems to be a good idea (at least in my case of a fixed file in the app bundle).
>
>
>> You can easily use a construct like GCD semaphores...
>
> Sounds too much work for now. Maybe to be considered later. Thanks for your ideas though.
>
>
> Kind regards,
>
> Gerriet.
>
>
> _______________________________________________
>
> 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
_______________________________________________
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