If your application requires the maximum possible performance from the file system, consider using BSD function calls to transfer data. Older routines require additional manipulation to work on non-HFS file systems and in non-Roman languages. The reason is that modern routines were written with Unicode and a wide spectrum of file systems in mind and were thus optimized for those environments. Modern routines that use the FSRef data type offer much better performance than the older FSSpec -based routines.
Hfs file system usage update#
If you are migrating legacy code to OS X, you should update your file-related code to use more modern APIs. See Examining File-System Usage for more information. This tool reports any file-system interactions and includes information about how long those interactions take.
To find out where your application is accessing the file system, use the fs_usage tool. Because of these factors, you should strive to reduce your application’s dependence on files as much as possible. And if the target file system is located on a server halfway around the world, network latency increases the delay in retrieving the data. File-system access times are generally measured in milliseconds, which corresponds to several millions of clock cycles spent waiting for data to be fetched from disk. Moving data from a local file system into memory takes a significant amount of time. Always analyze your application with the available tools to find the actual performance problems.įor more information about measuring file access performance, see Examining File-System Usage. If the server crashes, reading the file can take even longer. Something as simple as reading a preferences file might still take a long time if the file is located on a busy network server. For more information, see Cache Files Selectively.īe careful about making assumptions that a particular file operation will be fast. Strive to find an appropriate balance between reading from disk and caching in memory. Storing file data in memory improves speed until that memory gets swapped out to disk, at which point you pay the price for accessing the disk once again. Use the preferences system to capture only user preferences (such as window positions and view settings) and not data that can be inexpensively recomputed.ĭo not assume that caching file data in memory will speed up your application.
Reading is typically cheaper than writing data.ĭefer any I/O operations until the point that your application actually needs the data. For more information, see Be Aware of Zero-Fill Delays. The system must write zeroes into the intervening space to fill the gap. The kernel transparently clusters I/O operations, which makes sequential reads much faster.Īvoid skipping ahead in an empty file before writing data. Perform sequential reads instead of seeking and reading small blocks of data. For more information, see Choosing an Optimal Transfer Buffer Size. A single write of eight pages is faster than eight separate single-page writes, primarily because it allows the hard disk to write the data in one pass over the disk surface. Group several small I/O transfers into one large transfer. For more information, see Minimize File-System Access. Minimize the number of file operations you perform. As with all recommendations, it is important to measure the performance of the code being optimized before and after optimization to ensure that it actually gets faster. What follows are some basic recommendations for reducing the I/O activity of your program, and thus enhancing its performance. The following sections provide tips on how you can minimize this bottleneck to improve the performance of your code. Given the nature of disk-based storage, the file system can be a significant bottleneck to code. Links to downloads and other resources may no longer be valid. This document may not represent best practices for current development.
0 kommentar(er)
