Delay Any Unnecessary File I/O

If you can delay the reading of a file until after launch time, do so. The following list includes some files whose contents you may not need until after launch:

• Frameworks not used directly by your application—avoid calling code that uses non-essential frameworks until after launch.

• Nib files whose contents are not displayed immediately—make sure your nib files and awakeFromNib: code are not doing too much at launch time. See Simplify Your Main Nib File for more information.

• User preference files—user preferences may not be local so read them later if you can.

• Font files—consider delaying font initialization until after the application has launched.

• Network files—avoid reading files located on the network if at all possible.

If you must read a file at launch time, do so only once. If you need multiple pieces of data from the same file, such as from a preferences file, consider reading all of the data once rather than accessing the file multiple times.

Using fs_usage to Review File I/O

One way to identify the files used by your application at launch time is with the fs_usage tool. To monitor launch-time activity from your application, start running fs_usage in a Terminal window before you launch your application. The tool generates a continuous stream of data regarding all file system accesses.

To view file activity for all processes with the fs_usage tool, you would enter the following at the Terminal prompt.

% sudo fs_usage

If you wanted to limit the display to files accessed by a particular process, you could redirect the output through the grep tool. For example, to display file behavior for the TextEdit application, you would enter the following at the Terminal prompt:

% sudo fs_usage | grep TextEdit

After entering your root password, fs_usage begins running. There should be a flurry of activity generated by fs_usage when you launch your application. Once your application finishes launching, stop fs_usage by typing Control-C in your Terminal window.

Listing 1 shows a small portion of the output obtained during the launch of the TextEdit application. Pay attention to the second and fourth columns, which identify the operation and the elapsed time (in seconds) spent in that operation. You can generate additional info by passing the -w option to fs_usage or by maximizing the width of your Terminal window.

Listing 1  Sample output from fs_usage

10:56:13  CACHE_HIT                                                       0.000041   TextEdit

11:00:04  CACHE_HIT                                           0.000024   TextEdit

11:00:04  CACHE_HIT                                           0.000032   TextEdit

11:00:04  CACHE_HIT                                           0.000026   TextEdit

11:00:04  lstat           tions/TextEdit.app/Contents/MacOS   0.000052   TextEdit

11:00:04  lstat           tEdit.app/Contents/MacOS/TextEdit   0.000020   TextEdit

11:00:04  stat            /Applications/TextEdit.app          0.000012   TextEdit

11:00:04  access          /Applications/TextEdit.app          0.000008   TextEdit

11:00:04  lstat           ents/Resources/DocumentWindow.nib   0.000030   TextEdit

11:00:04  statfs          ents/Resources/DocumentWindow.nib   0.000019   TextEdit

11:00:04  open            ents/Resources/DocumentWindow.nib   0.000022   TextEdit

11:00:04  getdirentries                                       0.000067   TextEdit

11:00:04  getdirentries                                       0.000005   TextEdit

11:00:04  close                                               0.000007   TextEdit

The preceding sample data shows how much time was spent getting information about the TextEdit binary file and its document window nib file. In this example, most of the operations took only microseconds to perform. You should search your own output to see if there are any files being accessed that aren’t really needed, or whose access takes a significant amount of time.