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

CHAPTER 4

Performance Tuning

Brent Simmons, creator of NetNewsWire, once shared a story about a user
who filed a bug report about the poor start-up performance of NetNewsWire.
Upon discussion with that user, he discovered that they had more than
900,000 unread RSS feeds! The lesson I took away from that story is to expect
my users to put thousands of times as much data into my applications as I
would ever consider reasonable.

While we are working with Core Data, we need to consider the performance
impacts of our design. We might test with a couple of dozen recipes and expect
our users to load a couple hundred recipes into our application and test with
those expectations. However, our users cannot read our intentions or expec-
tations. As soon as we ship the application, some user somewhere will load
100,000 recipes into it and then file a bug report that it performs poorly.

4.1 Persistent Store Types

Four types of repositories are included with the Core Data API: SQLite, XML,
binary, and in-memory. (XML is available only on OS X, not on iOS.) In-
memory is technically not a persistent store because it is never written out
to disk. Binary is effectively a serialized version of the object graph written
out to disk. The XML store writes out the object graph to a human-readable
text file, and SQLite stores the object graph in a relational database. When
working with an iOS project, it is common to just use SQLite unless there is
a very specific reason to use one of the other store formats.

Atomic Stores
Atomic stores include XML, binary, and custom data stores. All of these stores
are written to disk atomically; in other words, the entire data file is rewritten
on every save. Although these store types have their advantages, they do not
scale as well as the SQLite store. In addition, they are loaded fully into