views:

188

answers:

2

First up, i realize this application has some design issues and while rewriting a huge chunk of it would probably solve my issues, I'm looking for a way to make things faster right now.

Basically I've got

viewController = [[MyViewController alloc] initWithNibName:nil bundle:nil];
viewController.view;

where MyViewController.xib is a rather complex nib file with a lot of intertwined controllers and views, some of which of course load their views and hierarchies from other nibs, but certainly not all. This takes around 7 seconds to load, which is a really long time considering this is an iPhone application.

The reason for forcing the view to load is that I'm also doing a some network requests in a parallel thread and once those have finished I'd like to set up quite a few things with these views.

My question is: how do I find out which parts of my nib are taking so long and what would be the best strategy to optimize this without completely rewriting the whole app (for now)?

+1  A: 

I have no idea if this would really work, but you could put logging statements in initWithCoder in each controller which will be called as each sub-xib loads. That might give you some clues.

I guess instruments don't give you anything useful ?

Andiih
The initWithCoder is a very good idea. Don't forget to call the super though.
TechZen
+1  A: 

The first thing to do is not to assume that the nib loading is the bottleneck without direct evidence that it is. Nib loading is highly optimized and very efficient. It is more likely that your bottleneck is the network request than the nibs. Use Instruments to get concrete data about where the app is spending its time before you do anything.

Assuming it is the nibs, Andiih answer is the best for profiling but it sounds to me like you've really got a design issue.

It sounds like you need to break your big nib up into smaller nibs.

Its common to have one view per nib. For example suppose you had an app that had a tabbar with five tabs. Then each tab had a table view which would open a detail view. In the normal setup, you would have 11 separate nibs. One nib would define the tabbar, one nib for each tab's view and then one nib per detail view. When the app started, only the nib for the tabbar and the first visible tab would load so you would only load two of the 11 nibs to start.

To optimize, the first thing to do is to break it down into the smallest possible individual nibs. A nib only loads when needed. You should place the functionality throughout your nibs such that you don't load the nib if its view is not immediately displayed.

Nibs are just lightweight data files so don't be afraid to create nibs that 99% identical. For example, I often use separate views for each portrait and landscape view. For the user's perspective, it's one view but I have three separate nibs. I do this in cases when its easy to use an entirely separate view than to rotate a single complex view. Each nib is loaded when when its orientation is used. If the orientation never changes, it's never loaded.

If you have a complex interface which changes significantly depending on a network request, it will be faster at runtime to have separate nibs for each variation than it will be to cram all the functionality into one nib.

TechZen