Important: This document may not represent best practices for current development. Links to downloads and other resources may no longer be valid.
Minimizing File Access At Launch Time
Accessing a file is one of the slowest operations performed on a computer, so it is important that you do it as little as possible, especially at launch time. There is always some file access that must occur at launch time, such as loading your executable code and reading in your main nib file, but reducing your initial dependence on startup files can provide significant speed improvements.
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.