Performance Tuning - Core Data - page 71

Warming Up the Cache
As we discussed in Section 4.3, Fetching , on page 67 , it is possible to preload
the data into the cache so that it is in memory when we need it. The easiest
way to perform this step is to execute a full fetch on a background thread.
For example, on launch of our recipe application, we could launch a back-
ground thread to retrieve all the Recipe entities. This would allow us to fill the
cache with the Recipe entities that we know are going to be presented to the
user, in turn allowing the main thread to grab those recipes from the cache
instead of the disk and give the user a smoother-running application in the
process. The magic behind this is based on how the NSPersistentStoreCoordinator
works. Whenever any request on any thread is performed, the data is held in
the NSPersistentStoreCoordinator as part of its cache. When another request is
made, no matter what thread it came from, for that same data it is retrieved
from the cache instead of requiring another hit to the disk.
Saving
The numbers discussed in Orders of Magnitude , on page 72 , also apply to
writing the data back out to the disk. In fact, writing to the disk is even
slower than reading from it. Therefore, it is more efficient for us to save data
back out to disk in batches. Saving after every record change causes our
entire application to feel sluggish to the user. Likewise, doing a huge write
while the application is attempting to exit gives the appearance that our
application has stopped responding and risks data loss.
As with most things when it comes to performance tuning, be aware of your
saves and how much data you are saving and how frequently. Try to do saves
during logical pauses in the application flow.
Deleting
It may come as a surprise, but deleting an object can cause a performance
issue. Let's review the data model from Chapter 3, Versioning and Migration ,
on page 37 . Imagine that in this later version of our application we want to
delete a recipe from the repository. When we delete the recipe, we have a
cascade rule set up to delete all the associated RecipeIngredient entities as well.
We also need to touch the Author entity, Ingredient entity, and UnitOfMeasure entity,
as shown in Figure 14, Impacts of deleting a recipe , on page 74 .
It is obvious why we need to touch the RecipeIngredient entity, but why do we
need to access all the others? This is because of the relationships between
the entities. For each relationship, we need to validate the relationship after
the delete and confirm that there are no dangling references. If these objects