[ae86_16v]

It is different than defragging right?

Sorry I am kinda new to Macs, so I am still getting use to all the terminologies.

But is there and windows equivalent?

Thanks.

[pat++]

Yes it is different. I think you are refering to the 'prebinding'.
Basically, it pre-calculates address information for libraries used by a given executable.

By pre-determining where a function in
another library is destined to be placed, the dynamic linker does not
have to resolve symbols at application startup time, and the application
can launch faster.

I don't think there is any windows equivalent... I heard Apple was working on a system which would automatically do prebinding when the application is first launched... This way, there will be no need to do prebinding manually after each install/update.

[Millennium]

There is no Windows equivalent to prebinding. In fact, there's no equivalent to prebinding on most platforms. But then, most platforms do not need it.

It has to do with Mach-O, the format used for most applications on OSX (there is another format, called PEF or CFM; it does not need prebinding). This format was invented back in the days of NeXTStep. NeXTStep was very big on object-orientation and modularity. One of the features of Mach-O was that fragments of code could be loaded and unloaded dynamically, so that only those parts of the code which were actually needed would have to be in RAM. Very useful back in the days when RAM was scarce and expensive.

This was a neat trick for Frameworks (most other operating systems call these "libraries"; Windows commonly uses the term "DLL" for the same thing). However, most apps generally need almost all of their code in RAM -or at least virtual memory- all of the time. This was a serious shortcoming of Mach-O, and it remains one today. Some of you may remember the infamous complaint at Unsanity, where they claimed that Mach-O was responsible for slowing down OSX by at least ten percent. That's an exaggerated figure, to be sure, but there is a speed hit.

Prebinding is a way around most of that. It stores additional information inside the app bundle, such that the whole app gets loaded on startup. This does cause it to take up more RAM than it otherwise would, but that's the classic tradeoff of RAM for speed at work.

Note, though, that I said it could get around most of the speed hit. Not all of it. There are still a few areas which prebinding does not fix, most notably the loading of GUI elements. These are still only loaded when needed, rather than loaded at startup. This might not seem major, but it's actually even more to blame than Quartz for the non-responsiveness of menus when they're first pulled down, or when you haven't used them for a while.

In short, Optimizing/Prebinding is a trick used to help eliminate a technique for loading apps which has far outlived its usefulness and hurts more than it helps nowadays. We can only hope that as OSX is tuned, the need for this technique is eliminated; there are many ways to do it, but something needs to be done.

One final note: It appears to be possible to prebind an app at compile time. If I understand this correctly, then developers should be able to do this themselves, eliminating the need for the user to mess with it. Rickster? CharlesS? You guys know anything about this? Am I just blowing smoke here, or am I onto something?

[proton]

Originally posted by Millennium:
<snip>

One final note: It appears to be possible to prebind an app at compile time. If I understand this correctly, then developers should be able to do this themselves, eliminating the need for the user to mess with it. Rickster? CharlesS? You guys know anything about this? Am I just blowing smoke here, or am I onto something?

No, this can't be done. The prebinding information changes for every version of the frameworks in the OS. Applications when you receive them from the developer are prebound for the versions of the frameworks and OS on the developers machine. Chances are you have, or will have, a newer version or older version of the frameworks, and hence the application needs to be re-prebound.

The reason that your machine does the prebinding after an update is because it is prebinding for the specific versions of things on your machine.

-proton

[normyzo]

Originally posted by Millennium:
One final note: It appears to be possible to prebind an app at compile time. If I understand this correctly, then developers should be able to do this themselves, eliminating the need for the user to mess with it. Rickster? CharlesS? You guys know anything about this? Am I just blowing smoke here, or am I onto something?

Contrary to what's been noted in one of the earlier posts, 10.2 _does_ prebind apps on startup. So it really doesn't serve to run things like XOptimize anymore since the app will just get re-prebound when it gets launched.

Each dylib (Framework) that you load has to be loaded at a non-overlapping address otherwise it cannot be prebound. The developer can specify where all the libraries are loaded at to make sure they are not overlapping, but this information can be overwritten by redo_prebinding and update_prebinding. See 'man ld' for more details.

Unfortunately, Apple's documentation on this subject is not quite clear. It takes some serious experimentation to get it all right. We've been trying to shoehorn prebinding into OpenOffice.org for a while, but its not been a top priority and we can't quite do it yet. Frustrating, also because we've got > 100 dylibs that need to be prebound.

Dan