Database Reference
In-Depth Information
need when we need it. If we fetch too little, our application will feel unrespon-
sive. If we fetch too much, our application will stall and potentially be killed
by the operating system.
Orders of Magnitude
Disk access is significantly slower than accessing memory. The times mea-
sured for each is six orders of magnitude different. This translates into disk
access being roughly 1 million times slower than accessing data that is stored
in memory, as illustrated:
Although the actual retrieval times are closer to a few thousand times slower,
the point is still clear. Avoid accessing the disk if possible. However, when
we have no choice but to access the disk, we must attempt to get everything
we need in one pass. Repeated small requests to the disk are significantly
slower than one larger request.
Prefetching
In Section 4.3, Fetching , on page 67 , we reviewed the different ways we can
retrieve the data from disk. To expand on that, consider each request we
make from the NSManagedObjectContext and try to retrieve all the data in one
request that the user is going to want to view. For example, if the user is going
to be editing a user record, load that user and all its relationships at once.
This will be significantly faster than grabbing the Person entity and then going
back to grab three Address entities, then two Phone entities, and so on. Use the
relationship prefetching option of NSFetchRequest to grab all of them at once.
If we can predict what the user is going to want to see and load it ahead of
their request, the overall user experience will be vastly improved. As we are
developing our applications, we need to look at each window, view, or sheet
and ask, ”What information will this part present?“ and make sure all of that
information is either already in memory or loaded at once. Having said that,
we need to balance this with information overload, as discussed in Section
4.5, Access Patterns , on page 75 .
 
 
Search WWH ::




Custom Search