What's the effect of cache to NSFetchedResultsController

Question

I read the doc of course, but I don't quite get the meaning of "setting up any sections and ordering the contents".

1. Don't these kinds of information come form data base?
2. Does it mean NSFetchedResultsController needs some other kinds of indices itself beside data base indices?
3. What's really going on when NSFetchedResultsController is setting up a cache?
4. Is cache useful for static data only? If my data update frequently, should I use cache or not?
5. How can I profile the performance of cache? I tried cache, but couldn't see any performance improvement. I timed -performFetch: but saw a time increase from 0.018s(without cache) to 0.023s(with cache). I also timed -objectAtIndexPath: and only a time decrease from 0.000030(without cache) to 0.000029(with catch).

In other words, I want to know when cache does(or does not) improves performance and why.

As @Marcus pointed below, "500 Entries is tiny. Core Data can handle that without a human noticeable lag. Caching is used when you have tens of thousands of records." So I think there are few apps that would benefit from using cache.

Answer 1

The cache for the NSFetchedResultsController is a kind of short cut. It is a cache of the last results from the NSFetchRequest. It is not the entire data but enough data for the NSFetchedResultsController to display its results quickly; very quickly.

It is a "copy" of the data from the database that is serialized to disk in a format that is easily consumed by the NSFetchedResultsController on its next instantiation.

To look at it another way, it is the last results flash frozen to disk.