Pre-binding libraries in Xcode 4

627 views Asked by At

I'm developing an app for a client and one of his devices (2nd gen iTouch on iOS4) is having issues starting the application. I've run a few allocation/leak tests and I concluded that there isn't anything wrong with my app's code. I noticed that there is an allocation spike at startup and I concluded that it's because of dyld which is dynamically linking the libraries on start up. How would I go about pre-binding the application in xcode4?

OS X forum seemed to be extremely non informative in that they assume you'd be able to find it. :/

Any help would be appreciated. Thanks!

(I also wish I could make a new tag for "prebinding")

2

There are 2 answers

0
Nik Reiman On BEST ANSWER

According to Apple, you shouldn't need to prebind your iOS applications. If you are getting big allocation spikes, I'm guessing it's due to your app's architecture rather than the underlying OS itself.

0
ipmcc On

The memory allocated by dyld should pale in insignificance compared to even the most basic allocations made by the earliest stages of the runtime. The Objective-C runtime and other system frameworks/libraries allocate a bunch of internal structures that are required for things to work correctly.

For instance, a quick test of an app that does nothing in main but make one call to NSLog(@"FooBar"); and then sleep (i.e. never even spools up UIApplication) performed 373 allocations for a total of 52K living.

To take it a step further, if you actually start up UIKit, like this...

UIApplicationMain(argc, argv, nil, NSStringFromClass([MyAppDelegate class]));

... you'll see ~600K in ~7800 living allocations once the app reaches quiescent state. This is all unavoidable stuff. No amount of prebinding will save you this. I suggest not worrying about it.

If you're seeing orders of magnitude more memory being allocated then, as Nik Reiman said, it's your application. At the end of the day, the memory allocated by the dynamic linker is totally insignificant.