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 <gerr...@mdenkmann.de> wrote: > > >> On 8 Oct 2014, at 13:42, Quincey Morris >> <quinceymor...@rivergatesoftware.com> wrote: >> >> (reposted after editing for length) >> >>> On Oct 7, 2014, at 22:12 , Gerriet M. Denkmann <gerr...@mdenkmann.de> 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 (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: > https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com > > This email sent to david.dun...@apple.com _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
