I am using the mmap function on iOS in a drawing app. I have a file that uses mmap and then I create a CGBitmapContext from that memory. The user may perform many core graphics operations on this CGBitmapContext with their finger, which will cause the memory to be updated constantly.
How often will this flush to the flash storage and is this a concern for wearing out the flash storage or for performance? I haven't noticed anything bad in my tests, but I am not familiar enough with mmap to know for sure.
iOS is pretty smart about how often it flushes to disk. I have noticed that when I background the app, as long as I call msync, i.e. msync(self.memoryMap, self.memoryMapLength, MS_SYNC); it flushes properly.
While I use the app, even if there is a crash or sudden termination, usually all data is saved. If I kill my app while debugging, sometimes the last few changes are not saved, but usually everything is saved.
So my conclusion is that this is not a concern. iOS is not constantly writing to disk, it is writing to disk at smart intervals.
Related
I am loading large amounts of data into Core Data on a background thread with a background NSManagedObjectContext. I frequently reset this background context after it's saved in order to clear the object graph from memory. The context is also disposed of once the operation is complete.
The problem is that no matter what I do, Core Data refuses to release large chunks of data that are stored as external references. I've verified this in the Allocations instrument. Once the app restarts the memory footprint stays extremely low as these external references are only unfaulted when accessed by the user. I need to be able to remove these BLOBS from memory after the initial download and import since they take up too much space collectively. On average they are just html so most are less than 1MB.
I have tried refreshObject:mergeChanges: with the flag set to NO on pretty much everything. I've even tried reseting my main NSManagedObjectContext too. I have plenty of autorelease pools, there are no memory leaks, and zombies isn't enabled. How can I reduce my Core Data memory footprint when external references are initially created?
I've reviewed all of Apple's documentation and can't find anything about the life cycle of external BLOBS. I've also searched the many similar questions on this site with no solution: Core Data Import - Not releasing memory
Everything works fine after the app first reboots, but I need this first run to be stable too. Anyone else been able to successfully fault NSData BLOBS with Core Data?
I'm assuming the "clear from memory" means "cause the objects to be deallocated" and not "return the address space to the system". The former is under your control. The latter is not.
If you can see the allocations in the Allocations instrument, have you turned on tracking of reference count events and balanced the retains and releases? There should be an indicative extra retain (or more).
If you can provide a simple example project, it would be easier to figure out what is going on.
I recently profiled my app using Xcode VM tracker instrument.I found that app has lot of dirty memory especially performance tool data. So i want to know what are the reasons of the huge dirty memory and performance tool data.
Any help would be appreciated.
Your app takes 51MB to store, when it is suspended. The performance tool itself adds an overhead of 30MB. Which leaves 20MB for your app.
From the listed items, it looks like your app is graphics heavy. In fact, it looks very similar to this post. Which makes me wonder if these objects are still processing or waiting to be released, when the app is suspended.
Alternatively, I wonder if you could free a lot of those animations and images when entering background, and reconstruct them when entering foreground.
Finally, note that Apple recommends removing strong references to images, data from disk and media to reduce dirty memory.
Since I just had the same problem, here is what I found:
The "Performance tool data" entries were from libBacktraceRecording.dylib.
You can disable backtrace recording in the scheme editor.
See the related question Memory leak with “libBacktraceRecording.dylib” in React Native ios application.
I'm trying to get a feel for the amount of memory an iOS app can reliably allocate to help me drive some design decisions. The app is going to involve real time synchronised processed audio and animation.
Other than writing code that loads up the frameworks I'll need then trying to progressively allocate memory until I get warnings, is there any way to determine this kind of thing?
The simulator doesn't let you select a specific hardware model, so I assume I can't even simulate this stuff.
You cannot determine how much memory an app allocate as far as I know. Always try to keep the lowest memory possible for your app.
The memory allocated to your app depends on many factors like : number of background process happening, amount of memory available, memory used by other apps, the device you are running etc..
So, its not a good practice to keep a maximum line for memory consumed by your app and design accordingly.
Also try to hold only the necessary memory you need and handle memory issue in the memory callback methods like 'didreceivememorywarning'. Always consider that you have the least amount of memory allocated by the OS.
I have a strange memory issue I'm having problems resolving and would appreciate some advice as to where else to look.
The program I have (iPhone App) has a function whereby it basically downloads loads of files, processes those that are JSON, and stores the rest to disk. The JSON processing is CPU intensive and can take several seconds per file, so I have a NSOperationQueue with maxConcurrency limited to 1 that handles all the heavy lifting, and a queue that manages the multiple files to download.
Ever since iOS5 came out, the App has had problems completing the download sequence without crashing and so far what I have tried is;
1) Changed the performSelectorOnBackgroundThread JSON processing to use a single NSOperationQueue so as to limit the number of background threads working with large objects.
2) Added NSAutoReleasePools inside loops that create multiple, large, transient objects.
3) Flushed the sharedURLCache to ensure the files aren't hanging around in the system cache.
4) Stored the JSON objects to disk using NSKeyedArchiver and passed the filenames between threads rather than the actual objects, to again try to mitigate the number and size of retained objects currently in use.
All of these at first seemed to make a difference, and when I look at the memory allocations, I've now got the peak usage down from just over 20MB (hence no wonder it was crashing) to under 10MB, and yet the app is still crashing with low memory as before.
I'm trying to trace what is eating the memory causing the app to crash and on this occasion I'm having real problems persuading Instruments to tell me anything useful.
Here's a typical trace (on an iPhone 3GS running iOS 4.3.5)
You can see that the PEAK usage was a tad over 7MB and yet shortly after, you can see the 2 flags pertaining to low memory, and then low memory urgent, followed by the app terminating shortly thereafter.
If I use the memory monitor, the cause of the crash seems clear enough - physical memory is being exhausted - look at the light green trace below. The low memory warnings co-incide (not surprisingly) with the physical memory running out.
There are no leaks showing FWIW either (I've done that in other runs).
It's not image caches or NSURLConnection caches and the only thing I can think of is that perhaps there are some bad leaks that aren't being detected ... but I'm having issues identifying them because if I click into all allocations to see the objects that are live, and then do a command-A to select them all (in order to paste them into a spreadsheet to see where the memory seems to be), at the point I hit command-C to copy them, Instruments beachballs and never recovers.
I really cant figure out what's going on. Does anyone have some advice on how to persuade instruments to show me some more useful information about what is using this memory?
Sorry I can't post any meaningful code fragments ... hopefully the instruments screenshots at least give you an idea about where I'm coming from.
The Leaks instrument isn't terribly useful for figuring out anything but the obvious leaks in your app.
What you are describing is an ideal candidate for heapshot analysis.
tl;dr Heapshot analysis allows you to see exactly how the heap of your application grows between any two points of time (where you determine the points).
I'm using NSOperationQueue to manage a phase of an iOS application which is quite long so I would like to manage it asynchronously. Inside that phase I allocate big arrays in C by using directly calloc functions.
With big I mean a 1024x256 bidimensional array of floats and similar things.
If everything resides on the main thread than the app locks up while computing but everything goes fine, if, instead, I move the heavy part to a NSInvocationOperation then I got many strange results, with debugger sometimes I get a strange message in console stating
No memory available to program now: unsafe to call malloc
so I was wondering if threads managed by an operation queue have some different restrictions compared to main thread, and in case what is better to do to get around this issue.
There's no restrictions that I know of.. however, you may be hitting the edge of available RAM. Since iOS doesn't do virtual memory, when memory gets low, it'll send a warning to other apps to free up RAM. That may be the source of your issue.
Use instruments to profile how much RAM you're using. If it's more than about 20MB or so, you're probably in danger of being terminated due to excessive memory usage anyway.