Re: Library loading policy on Mac OS X with Cocoa
Re: Library loading policy on Mac OS X with Cocoa
- Subject: Re: Library loading policy on Mac OS X with Cocoa
- From: Art Isbell <email@hidden>
- Date: Wed, 27 Jun 2001 11:45:11 -1000
On Tuesday, June 26, 2001, at 05:17 PM, Chris Hanson wrote:
At 8:07 AM -0500 6/26/01, Eric Peyton wrote:
Because if it loaded it at application launch then *every*
application, including those that NEVER make a sound would
incur that startup/launch penalty. Everyone wants there apps
to launch faster, not slower, and in order to do this, less
code needs to be loaded at launch.
I completely fail to understand this position.
Lazy resource allocation should always be considered at all
levels from program design to shared library loading. If
resource allocation is so slow that lazy allocation might cause
delays that would be worse when needed as opposed to at launch
time, then don't allocate lazily. It's analogous to the
just-in-time shipping policies that are all the rage in
manufacturing these days - don't order something until just
before it's needed.
On Mac OS 9, every reference to a linked library is fixed up at
launch time. The same is true for Windows, Linux, Solaris,
BeOS, and pretty much every other platform out there.
Just because everyone else does something doesn't
necessarily make it better, right? There's much about Cocoa, OS
X, etc. that differ from everyone else and that most
knowledgeable people consider to be better. Remember, "Think
Different" :-)
In fact, on Mac OS 9 if you have virtual memory turned off (as
I do) you don't even get demand paging of libraries or
executables -- everything is physically loaded into RAM at
launch!
This can a good thing if you aren't multitasking, but not
very nice for a multitasking OS like OS X.
I think there's probably a subtle, fundamental piece of
functionality that's broken in the application launch
functionality in Mac OS X.
If something's broken, it's been broken for several years.
I recall when NeXT allowed developers to create their own
frameworks that were first-class citizens compared with NeXT's
frameworks, launch times increased. I don't know the cause and
what can be done to fix the problem (I agree that it's a
problem). Maybe it's related to the Objective-C runtime which
may need to recreates its dispatch tables as new classes are
added. I don't think a comparison of app launch times in
Classic vs. OS 9 is a valid comparison.
Once it's fixed I expect things will get much better and we
won't have to use silly hacks like lazy loading of libraries
and lazy import resolution to get it around it.
I doubt that many programmers consider lazy loading to be a
silly hack in general.
Art Isbell
Apple iServices Technical Support
http://www.apple.com/iservices/webobjectssupport/
+1-808-591-0836