On Feb 22, 2009, at 5:24 PM, Andrew E. Davidson wrote: The speakHere sample app passes NO for this argument. The document does really say much about when or why you would want to set this value one way or the other. Any thoughts or suggestions?
This argument gets passed down to the filesystem, telling it whether the read operation should be cached. This is an optimization. The tradeoffs are
- If you think you will be reading the same data in the near future, and need to get it as quickly as possible, you should cache the read.
- Otherwise, by not caching the read, you won't be causing any already cached data/code from other apps to be flushed from memory.
Caching would be good if you're playing sound effects in a real-time game, since the data size is small and you need low latency.
Caching would be very bad if you're compressing a 900MB AIFF file. By caching 900MB of audio data, you cause 900MB of stuff that used to be in memory to be evicted to make room. After the conversion is done, the system's going to thrash and feel really slow for a while because doing stuff in other apps will require things to page back in.
On the iPhone, you probably want to avoid caching, because (a) RAM is very limited, and (b) the "disk" (flash) has zero seek time, so latency isn't as much of a problem.
—Jens |