Resources | Resources |



Use of IFile_SetCacheSize()

The IFile_SetCacheSize() method sets the size of the buffer to be used for caching the file instance on which it is called. In certain cases, this may improve file system performance, but there are many other cases in which it will hurt performance instead. You should choose the files you cache carefully and measure application performance before and after enabling caching to see if the caching really does help, rather than caching files with the assumption that it will improve performance.


The file system (EFS) on which Brew MP's file interfaces are based does its own caching, keeping 100 512-byte buffers of the most recently read data.

Brew MP's file caching code only caches a file for a particular instance of IFile; when the IFile interface is released, so is the cache. When the IFILE_SetCacheSize() call is made, Brew MP immediately allocates a cache buffer of the given size and reads the amount of the file specified in the call into the buffer.

Suggestions for the use of caching:

  • For simple sequential access to a file, EFS file caching will provide byte-by-byte access to the file without going to NAND for each byte. The extra layer of Brew MP file caching, though it might avoid kernel transitions, will not likely improve performance in this case.
  • The cache for an IFile is released when the last release is done on an instance of IFile. Repeatedly opening, caching, and releasing a file will likely hurt performance because of the repeated loading of the cache.
  • The cache is per IFile instance. Opening and caching the file twice will result in the file being read from NAND twice, and two copies of the file cache in memory, rather than one. If a file is cached, you should share a single instance of the IFile rather than creating two.
  • Calling IFile_SetCacheSize() immediately reads from the file to fill the cache. Applications should not call this method until they are ready to read from the file. Calling IFile_SetCacheSize() before the application is ready to read may introduce a delay while the cache is filled for a file that may never be accessed.
  • One place where caching may improve application performance is for a file that is accessed randomly throughout the life of the application (similar to a resource file). In this case, having an IFile instance that is cached and open for the application's lifetime is likely to help. This is what Brew MP does internally with resource files accessed via the IShell_LoadResXxxxx methods. Even in this case, though, you should measure performance with and without caching to see if it really does provide a performance improvement.