Difference in performance: loadNibNamed vs. programmatically

Question

I have a viewcontroller, that contains many custom UIViews. The custom UIView I tried to define it using InterfaceBuilder (IB), and load it within initWithFrame using this code:

NSArray *xib=[[NSBundle mainBundle] loadNibNamed:@"DayView" owner:self options:nil];

The view controller behaved extremely slow, so I decided to try to load the items of the custom uiview programatically. Vòila, and the speed was increased by a factor of about 7.

How come the difference between loading XIB files and using "clean" code is so big? My first hypothesis that I could think of was that IB is setting a lot of properties by default, whereas they simply are nil when defining them in code. But it cannot explain the huge performance difference! I haven't found any posts that explicitly warn you against using IB of performance reasons.

EDIT: I just found this link and therefore this blogpost which explains interesting things about when xib files are loaded from disc. I guess that loading from disc explains the difference. /K

Roorback

You can check this performance test here: cocoawithlove.com/2010/03/… .It is a bit old, but I think still relevant. Also read the Conclusions, maybe you'll find out why its so slow in your case – Allstar

I just happened to encounter this issue today. Swiching to programatically created UIView, I can see about 5 times faster. And Time Profile stops registering it as the bottleneck. – Juniper

Answer 1

Here is Some point i got and also found from my experience and google.

=> I've done it both ways and here's my two sense:

If your view is relatively simple and you are confident it is not going to be changing it much; then Xib away. If not, I recommended programatically all the way because it has at least 3 large benefits:

1) You gain a much deeper knowledge of how everything is working behind the scenes, which vastly aids debugging if there are problems

2) Complete control and customization over everything, so if there are changes it is easy to implement

3) Less confusing; this could be a personal preference but if there are lots of actions being called from buttons and such I find the interface builder arrow zig-zag hullabaloo a lot more confusing than programatically.

=> progmatically define control is more time consuming process then using XIB. Because to create all the controls and positions etc on the fly.

=> I have also noticed that the files related to loading a view programmatically use about a half as much secondary memory as xib files. I am not sure if that translates into a larger application, but it might be something to consider in lager applications

=> I was doing some reading and I think I found something that sort of seals the deal in favor of programatically. Turns out the Xib files implicitly use the imageNamed method to load their images into memory, which has a well known caching "feature" that is problematic for memory. Also I hear that IBOutlets are a significant memory management problem.

All these interface builders are very very nice tools but if you dont know what your doing and you dont know what those tools are doing you

1. dont really learn anything

2. can cause serious problems in your code later

and as soon as you understand how everything works its perfectly fine to use those little helpers...

i have gone through the same when learning html, flex, swing and cocoa touch... and it might take a little longer in the beginning but once you understand it and can write helper classes/methods things will work very fast and good for you.

Just found some usefull information/tips about xib:

Keep Your Nib Files Small Most new projects in Xcode come with one or two preconfigured nib files. A mistake made by many developers who are new to Interface Builder is to place all of their application’s windows and menus in these one or two nib files. The reason for the mistake is often convenience. (The template project usually loads the preconfigured nib files automatically, which saves the developer from having to add more nib-loading code.) Unfortunately, relying on this convenience can often lead to diminished performance and added memory pressure on your application.

When a nib file is loaded into memory, it is an all-or-nothing endeavor. The nib-loading code has no way of knowing how many objects are in the file or which ones are important, so the entire file must be loaded into memory. From this in-memory data, individual objects are then instantiated. For Cocoa and iPhone applications, all of the objects in the nib file are instantiated right away so that outlet and action connections can be reestablished. If your application uses only some of the nib-file objects initially, having all of the objects in memory is a waste.

For all projects, it is better to design each nib file so that it contains only those objects that are needed immediately in a given situation. When loaded into memory, such a nib file uses the smallest amount of memory possible while still having everything it needs to get the job done. Here are some design choices to consider when organizing your nib files:

For your application’s main nib file, include only your menu bar (or in the case of an iPhone application, just the main window).

For document nib files in Mac OS X, include only the document window and the objects (such as controllers) needed to display that window.

For other nib files, focus the nib file on a key object, such as a single window or panel that you intend to display. All other objects in the nib file should then facilitate the immediate operation of that window or panel.

For windows that change their embedded view hierarchies, if the hierarchy changes infrequently, consider storing any additional hierarchies in separate nib files. Load each view hierarchy only as it is used.

If you already have large nib files, you can use Interface Builder’s refactoring tools to break them into several smaller nib files. For information on how to use Interface Builder’s refactoring tools, see “Refactoring Your Nib Files.” For information about how to load nib files explicitly from your code, see Resource Programming Guide.

But My personal opinion as a professional programmer (as in i am a software developer) is that its always better for beginners to start with the programmatical way just to learn and understand how everything works

Agitation

Perhaps you could focus on the performance implication, this reads like a general anti-interface builder blog post and I'm not seeing much about the performance implications. – Inaccurate

@CarlVeazey. this is basic point with performance(also speed) . first read it then give down vote...undertand . – Agitation

@iPatel. Thanks for your post. A bit long and messy, but you state a few interesting points that I might dig deeper in to. – Roorback

@kjoelbro- hahaa , i know its very long..but it may be helpful for beginners..thanks :) – Agitation

If its a project with a long lifecycle where a lots of devs are going to work with, it will be much better to work with xibs since it's less confusing – Eulaliaeulaliah