Pre-allocate memory in iOS

Question

My app loads 5 UIButton (2 of which use custom images), a UITextView and a UITextField on the main thread as reaction to a button press. Testing on an iPad 2 this takes a few seconds, but only the first time. After that, even after releasing everything, it loads a lot faster. To me it seems like the iPad first has to free some inactive memory in order to be able to load my stuff. Can I somehow request more memory at my disposal in advance to speed things up a little?

SOLUTION: As the problem was caused by the keyboard, this is the solution that worked best for me:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  // Preloads keyboard so there's no lag on initial keyboard appearance.
  UITextField *lagFreeField = [[UITextField alloc] init];
  [self.window addSubview:lagFreeField];
  [lagFreeField becomeFirstResponder];
  [lagFreeField resignFirstResponder];
  [lagFreeField removeFromSuperview];
}

I also delayed the adding of my RootView a little so the lag does not mess up animations I have going on there in the beginning.

possible duplicate of [Super slow lag/delay on initial keyboard animation of UITextField](http://stackoverflow.com/questions/9357026/super-slow-lag-delay-on-initial-keyboard-animation-of-uitextfield) — David Berry, May 28 '14 at 13:50
The bottleneck here is loading images from disk. You should load them on another `dispatch_queue` or `NSOperation` — toasted_flakes, May 28 '14 at 13:56
As per the various comments saying it's probably other things than freeing memory: you've no evidence to support that conclusion and optimisation should always be evidential. Use Instruments and find out what the real bottleneck is. — Tommy, May 28 '14 at 14:28

score 1 · Accepted Answer · edited May 23 '17 at 12:07

That couple second delay is the first time that your app shows the keyboard. There are a few tweaks you can do to remedy that delay, but they are inelegant at best.

It's not due to your code or allocating your object memory, it's Apple's way of doing this (saving memory in case your app never uses the keyboard).

Check this link out and read more like it. You will understand the problem and possible work arounds.

score 1 · Answer 2 · edited Jan 25 '16 at 16:45

1

Assuming that char is 1 byte and there are 1 048 576 bytes in 1 megabyte you can use following code

int megaBytesNeeded = 1; // For more memory, run allocation in a loop
size_t size = sizeof(char) * 1048576 * megaBytesNeeded;
char *array = malloc(size);
memset(array, 0, size); // Actually use memory, iOS allocates lazily
free(array);

But this is not the solution you should be using. I think you should open Instruments.app and use time profiler to see what causes your glitch. Select time period (that causes a glitch) and look for selector that takes significant amount of time.

edited Jan 25 '16 at 16:45

Emiswelt

3,909
1
38
56

answered May 28 '14 at 14:03

Marek H

5,173
3
31
42

I've been actually using this and it works. Very useful for realtime-applications that need to rely on memory to be immediately available. However, someone should avoid such code at all costs. It's not safe to rely on the memory not being allocated again by other applications until usage. – Emiswelt Jan 25 '16 at 15:56
@Emiswelt: please post your solution `int megaBytesNeeded = 1; // For more memory, run allocation in a loop size_t size = sizeof(char) * 1048576 * megaBytesNeeded; char *array = malloc(size); memset(array, 0, size); // Actually use memory, iOS allocates lazily free(array);` on it's own answer. – SwiftArchitect Jan 25 '16 at 16:25

score 0 · Answer 3 · answered May 28 '14 at 15:04

Do not assume anything. Profile your application using Instruments and see what is going on.

It is very likely that what you are seeing is image caching. If you load images using imageNamed, the system caches the images so the next time they are loaded.

Again, though, I would not assume that is the case. Use Instruments.

Pre-allocate memory in iOS

3 Answers3