Re: Guidelines for NIB usage
Re: Guidelines for NIB usage
- Subject: Re: Guidelines for NIB usage
- From: John Stiles <email@hidden>
- Date: Wed, 25 Jul 2007 11:08:38 -0700
On Jul 25, 2007, at 11:01 AM, I. Savant wrote:
On 7/25/07, Kevin Hoffman <email@hidden> wrote:
With .NET you have to manually instantiate each window, but your
entire
Assembly is loaded into memory at app startup time anyway so
deferring
the instantiation isn't really gaining you much.
An important thing to keep in mind, yes. The more UI your app has to
create at launch time, the longer the launch time will take.
Of course there's a trade-off (isn't there always?): In the
Preferences example I gave previously, the first time the user *does*
open the preferences window (causing the NIB to load) during that
session, there will be more of a delay than each subsequent time
during that session. For huge UI chunks, this may or may not be
acceptable.
In the case of many complicated "editors", the load-time
requirements change ... I have no idea off the top of my head
(enlightenment, anyone?) if any optimization / caching is done for
NIBs, but if not, suddenly the idea of creating a new complex editor
window by loading it from a nib for each object you want to edit
requires more serious deliberation.
I'd *love* to hear from the community about that one, though. I
honestly don't know for sure but don't care enough at the moment to
look it up myself. :-D
Honestly, I think I have the minority viewpoint, but I haven't
observed NIB loading to take a noticeable amount of time or resources
in most of my apps, even if I slap all the windows into one big NIB.
Imagine your average app has ten windows and each contains ten
controls. That's 100 things—in my mind, that's just not that much
data. I think for a typical app with not a ton of windows, you are
better off loading them all at once rather than slicing it up into
tiny chunks. For example, imagine your laptop user goes to visit some
rarely-used window five minutes after the app has started up—there
will be a huge delay while the hard drive spins back up so it can
read 2K of NIB data off the disk. Frankly I'd rather just have that
2K of data available from the start (or in the worst case, 20K of
data, assuming it expands 10x during the process of loading it) and
then the window opening will be instantaneous.
If your app is loading slowly and you can prove it's due to huge
bulky NIBs, I completely agree that you should divide them up, but I
wouldn't do it until you can prove that it's a measurable cost, and
so far that has yet to happen for me.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden