Prebinding Explained

What is prebinding and when does it need to updated?

Really Short Answer

Under 10.1, prebinding never needed to be updated on anywhere as regular of basis as a lot of people assumed. The only time prebinding information would be out of date is if you installed an application on the boot volume via drag-n-drop. In that case, only that application's prebinding information would be out of date and updating the prebinding would only affect the freshly installed app's launch time.

Under 10.2, prebinding information is automatically updated as a normal part of system operation. There is no need to ever manually update prebinding information.

Prebinding only affects application launch times and only for native OS X applications. It does not affect the runtime performance of an application, the speed with windows can be resized or moved, or the speed at which finder updates various views. There has never been any reason or benefit to updating prebinding on a regular schedule.

Short Answer

Under OS X 10.1 and prior, the only time it was ever necessary to update prebinding on a machine was after installing a new application onto the boot volume (apps on non-boot volumes cannot have their prebinding updated) that did not use Apple's Installer application. System updates should update the prebinding (the really long "optimizing system" phase) and, as such, there is no need to update prebinding after system updates.

Prebinding only affects application launch times. Applications on volumes other than the boot volume cannot have their prebinding information updated (though they can be prebound).

Under OS X 10.2, prebinding is automatically updated. If an application is launched whose prebinding information is out of date, an automatic mechanism is triggered that will cause the application's prebinding information to be updated (as well as all libraries the application uses).

In other words, on OS X 10.1 and prior, there was never a need to update prebinding more often than, say, exactly once after a new application is installed and only if the app is installed on the boot volume. Even in this case, updating the prebinding will only optimize the launch time of that new application.

Under 10.2, there is no reason to update the prebinding information manually.

Long Answer

Under Mac OS X, a mechanism called prebinding is used to accelerate the launching of applications. Applications on Mac OS X, like applications on every other modern operating system, are composed of more than just a single file that is executed by the computer. Applications are built on top of libraries full of functionality. Some of the libraries are provided by the operating system vendor -- Apple provides more than 150 libraries in the default installation of OS X. Everything from Cocoa to Carbon to the Web Services API to the libraries used by iPhoto to talk to your mac.com account are implemented in libraries.

Instead of including the contents of the library into an application directly (a process known as static linking), a developer will cause their application to dynamically link the needed libraries. This has two very distinct advantages.

First, if five applications are currently running that all use the Cocoa framework (a framework is simply a mechanism that contains a dynamic library and all resources associated with the library in a single directory), the shared memory mechanism kicks in and all five applications share the same chunk of memory to hold a copy of the Cocoa dynamic library. Not only does this save memory, but applications that use the Cocoa framework that are launched after at least one app that uses the Cocoa framework has been launched will not have to load the Cocoa framework and, as such, will launch faster.

Secondly, when Apple ships a system update that upgrades the frameworks shipped with the system, applications that dynamically link against that framework (or library) will automatically take advantage of the new features or bug fixes provided in the new version of the framework or dynamically linked library.

Back to prebinding...

A dynamic library is just a big collection of functionality that the application can use to implement whatever features it needs. When an application dynamically loads a library, it has to find all of the chunks of functionality before it can use them. Each bit of functionality-- each function, class, constant, global variable, or whatever-- is represented by a symbol.

As the application loads, it looks up each symbol that it needs from all the dynamic libraries that it uses and binds that symbol into itself. Once a symbol is bound, the application can then use that symbol-- that function, class, constant, global, etc.. -- as a part of its implementation.

The process of binding each symbol is quite time consuming. There may be thousands, if not tens of thousands, of symbols that have to be bound. Not only does the application have to bind all of the symbols from the libraries that it uses, but each library has to also bind all of the symbols that the library uses from other libraries.

Obviously, eliminating this manual binding process would improve applciation launch times.

Prebinding is a means by which application launch times are improved on OS X by eliminating the manual binding process. When an application or dynamic library is prebound, it means that the application or dynamic library contains a cache of all of the symbols it needs in an already bound state. When the application is launched, it automatically uses this information cache such that all symbols are bound without having to go through the arduous task of binding each symbol individually.

Every time a new version of a library is built, all of the locations of the symbols within that library change. When this happens, all prebinding information that was built against the previous version of the library is no longer valid. When an application is launched, OS X automatically detects this situation and falls back to the manual binding process.

Under 10.2, the system automatically updates prebinding information any time an application is launched that lacks complete prebinding information. This happens automatically and in the background.

Conclusion & Thoughts

There have been few aspects of OS X that have been as sorely misunderstood or abused as prebinding. There have been many, many applications written that make outrageous claims about the affects they will have on system performance through mere prebinding. Hopefully, this document will shed some reality on the whole subject. It was written from an informed perspective of a long standing developer who has both read the documentation on the subject several times and who had a couple of long conversations with the engineer at Apple who is primarily responsible for the prebinding infrastructure in OS X (who asked not to be identified directly).

Of course, this all begs the question: If updating the prebinding on your system is such a relatively useful task, why did I ever write Xoptimize in the first place?

I originally wrote Xoptimize in answer to a question that was posted on one of the developer mailing lists. Specifically, someone asked how they could run a command line application with adminstrator privileges while parsing and displaying all of the commands output. This picqued my interest as I forsaw the need to do the same in one of my applications.

In response to the question, I wrote and released Xoptimize as freeware, including fully documented source. It was never meant to be a commonly executed end user application (to put things in perspective -- the only time I have ever updated the prebinding on my systems has been as a part of testing the development of Xoptimize).

That Xoptimize has seen well over 100,000 downloads and was the first in a long series of applications that do exactly the same thing came as a big surprise. The the whole subject of prebinding has spawned some of the commentary and claims that can be seen throughout the various product reviews of applications that do prebinding has generally been amusing and occasionally pathetic.

Xoptimize continues to work on OS X 10.2 though there is basically no reason to ever run the application on 10.2 The source code remains valid and provides a [hopefully good] example of working with the Authorization APIs and parsing output from a command line tool (there are more effecient means of parsing, but-- given context-- the one demonstrated works fine).

Some of the other products that do the same thing:

SpeedMeUp Pro & SpeedMeUp Lite

Moo (No, I had nothing to do with this -- the author basically copy/pasted the source to Xoptimize into his application. It was amusing to see the reviews that claimed that Moo worked better than Xoptimize or vice-versa.)

Mox Optimize (Also includes many other features and tweaks to the operating system -- prebinding is but one of about 40 features)

maintain1 X

Pacifist (updating prebinding is a minor feature in the app -- the app, itself, is an incredibly useful tool for inspecting and extracting bits and pieces of installer packages. I use it on a regular basis to keep track of exactly what each Apple system update is changing within the system.)

This article is not intended to provide a deep technical explanation of exactly how prebinding works. It uses a number of simplifications that are effective in context, but gloss over some of the subtleties and details of the underlying mechanisms. If you wish to learn more, I suggest reading the following man pages:

fix_prebinding(8)        - Given an application that is not launching prebound, fix whatever's needed

redo_prebinding(1)       - redo the prebinding of an executable or dynamic library

redo_prebinding(3)       - library functions

update_prebinding(1)     - Update prebinding information for newly changed files

dyld(1)                  - the dynamic link editor

dyld(3)                  - low level programatic interface to the dynamic link editor

dyld_debug(3), dyld debug(3) - programmatic interface for debugging a task using the dynamic link editor

27-Aug-2002 Update

Updates in response to various emails.

The "Optimizing System" phase of installing packages is updating the prebinding of the package contents. In particular, it uses the BOM (Bill of Materials) file to only update the prebinding of the components that were installed by the package. It isn't clear exactly how this affects other prebindable resources that depend on the contents of the package. However, 10.2's automatic prebinding mechanism will take care of anything whose prebinding information is out of date.
You do not need to have the developer tools installed for 10.2's automatic prebinding mechanism to be active.
The automatic prebinding mechanism is triggered by the dyld (dynamic link editor - see man page) subsystem. In particular, when the dyld detects that an application's prebinding information is invalid or out of date, it sends a message to the mach_init (the master intra-process communication daemon under mach -- see man page) which then invokes fix_prebinding to attempt to update the prebinding information. This happens transparently to the user. You can monitor automatic prebinding activity via the /var/log/system.log log file (try 'tail -f /var/log/system.log' in a Terminal window).

If you set the DYLD_PREBIND_DEBUG environment variable prior to launching an application or command line executable, the system will dump information regarding the state of prebinding information in the executable. I.e.:

[bumbox:~] bbum% ~/Applications/SSHPassKey.app/Contents/MacOS/SSHPassKey 
dyld: in map_image() determined the system shared regions ARE used
dyld: /Volumes/Data/Users/bbum/Applications/SSHPassKey.app/Contents/MacOS/SSHPassKey: prebinding disabled because time stamp of library: /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa did not match
dyld: /Volumes/Data/Users/bbum/Applications/SSHPassKey.app/Contents/MacOS/SSHPassKey is not on root volume, not re-prebinding.
dyld: 54 two-level prebound libraries used out of 54