Performance Tuning - Core Data: Data Storage and Management for iOS, OS X, and iCloud - page 69

In this example code, we create a new NSArray that has one NSString within it
that corresponds to the name of the relationship within the Person entity. We
can get even more clever with this request by using a keypath in the NSArray
and specifying a second level of objects to include in the fetch. For example,
if our Address entities had a relationship to a postal code lookup table that
contained the city and state, we could change the NSArray creation line to the
following:

NSArray *relationshipKeys = [NSArray arrayWithObjects:@ "addresses" ,
@ "addresses.postalCode" , nil];

That would cause Core Data to retrieve two levels of relationships as faults.
In addition, this call does check for duplication before executing the requests
and thereby can be used safely when mixing keypaths. In other words, the
postalCode relationship, which is probably many to many, will not be retrieved
more than once.

NSFetchRequest and Disk Access
Every time an NSFetchRequest is executed, it hits the disk. This is an important
point to keep in mind when we are working with NSManaged-Object objects. If we
are doing joins, adding objects to a relationship, and so on, it might seem
easier and cleaner to perform an NSFetchRequest to check whether the object is
already in the relationship or check for a similar function, but that action
can hurt performance significantly. Even if we have all the relevant objects
in memory, an NSFetchRequest is still going to hit the disk. It is far more efficient
for us to use that NSPredicate against a collection that is already in memory.

We have seen in this section that with a SQLite persistent store, we have a
lot of control over how our data is loaded into memory. We can tailor the load
to fit our exacting needs. All of these options can be a bit overwhelming, but
there is one good rule of thumb. Try to load only the data you need at that
moment in one pass. Every fetch request can take quite a bit of time, and
since the fetch requests are normally performed on the main thread, they can
damage the user experience of your application.

4.4 Faulting

Firing faults individually is one of the most common, if not the most common,
cause for the poor performance of Core Data applications. Faults are a double-
edged sword that can make great improvements to the speed and performance
of our applications or can drag the performance down to the depths of the
unusable. The single most valuable performance improvement we can make
to a Core Data application is to make sure we are fetching only the data we