What's the effect of cache to NSFetchedResultsController

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.

---

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.

---

From the documentation of NSFetchedResultsController:

Where possible, a controller uses a cache to avoid the need to repeat work performed in setting up any sections and ordering the contents

To take advantage of the cache you should use sectioning or ordering of your data.

So if in initWithFetchRequest:managedObjectContext:sectionNameKeyPath:cacheName: you set the sectionNameKeyPath to nil you probably won't notice any performance gain.

---

From the documentation

The Cache Where possible, a controller uses a cache to avoid the need to repeat work performed in setting up any sections and ordering the contents. The cache is maintained across launches of your application.

When you initialize an instance of NSFetchedResultsController, you typically specify a cache name. (If you do not specify a cache name, the controller does not cache data.) When you create a controller, it looks for an existing cache with the given name:

If the controller can’t find an appropriate cache, it calculates the required sections and the order of objects within sections. It then writes this information to disk.

If it finds a cache with the same name, the controller tests the cache to determine whether its contents are still valid. The controller compares the current entity name, entity version hash, sort descriptors, and section key-path with those stored in the cache, as well as the modification date of the cached information file and the persistent store file.

If the cache is consistent with the current information, the controller reuses the previously-computed information.

If the cache is not consistent with the current information, then the required information is recomputed, and the cache updated.

Any time the section and ordering information change, the cache is updated.

If you have multiple fetched results controllers with different configurations (different sort descriptors and so on), you must give each a different cache name.

You can purge a cache using deleteCache(withName:).