I.ndigo Blog. Artigo

Following the last post, iPhone Persistent Store Overview, I.ndigo begins the performance experiments series, on iPhone persistent store alternatives, with Core Data, Apple’s official framework for this purpose.

Introduction

Core Data for iPhone was introduced in the 3.0 version of the SDK, although it was previously available for Mac OSX. The framework implements an Object Graph Manager, giving applications the ability to manage data, including inserting new records, applying changes, undoing and redoing them and also the ability persist them.
It provides a high level API that abstracts all data management rules, as unique identifiers, model consistency and data validation, insertion, update and deletion, as well as data store creation and operation.

Data modeling abstraction is achieved by Xcode’s integrated graphical data modeling tool, where  the developer must describe an entity-relationship diagram representing and the system’s data. Xcode then generates all the classes and files needed to manage and optionally persist the data.

The persistent store layer abstracts the database and file store to the developer. The iPhone SDK provides SQLite and a binary format and the Mac OSX SDK also provides XML persistence. Either way, the implementation details stay apart from the developer, who should only care about objects and its properties.

Core Data Architecture

To implement the previously described functionality, a flexible and solid architecture was created, as seen in the following diagram:

• NSManagedObjectModel: Created on run-time, based on the project’s data model, which is designed by the developer in the integrated graphical tool, represents the hole system’s data;

• NSManagedObject: Represents each entity and its properties, modeled by the developer. Those properties includes attributes and relationships;

• NSManagedObjectContext: Provides all the mentioned functionality to the Managed Objects, as fetching and deletion; It is aware of and has access to the Persistent Store Coordinator;

• NSPersistentStoreCoordinator: Provides an interface to the data persistence layer.

As mentioned before, Core Data is not limited to data persistence. All aspects of data management are separated from the persistence layer and can be used without it.

Testing Methodology

Environment

iPhone 3G 8GB

Xcode 3.2.3

iPhone SDK 4.0

iOS 4.0

Release Configuration

Data Model

Testing Scenario

SQLite was chosen over binary format because it is the only type that is capable of partial object graph loading, making use of the lazy fetching feature, what is very important for the powerful, though limited iPhone hardware capabilities.

Also, a 10000 lines database, or 10000 persistent objects, was considered enough for performance testing purpose. Core Data persists its objects by saving all the NSManagedObjects present in the NSManagedObjectContext by once. Therefore, the testing methodology for the insertion tests included batch operations, with different of objects quantity per save, as the following table describes:

Batch size	Times
1	10000
10	1000
100	100
1000	10
10000	1

The following testes will be performed:

1. Insert without join tables
   The main objective of this test is to determine the insertion performance degradation, according to the database size. Therefore, following the previous ta ble, 10000 objects will be persisted.
2. Insert with join tables
   This test purpose is to decide how much the number of table joins affect the performance. Therefore, a smaller database will be used (2000 lines) with join quantity from none to four.
3. Select without join tables
   In this test two approaches will be considered: fetching objects by its attributes and getting them by their identifier. The performance is going to be measured, until the persisted object’s count reaches 10000.
4. Select with join tables
   This tests aims to identify the selection performance degradation, according to the number of object relationships (table joins). Since this is the heaviest test, once the data must be inserted and then selected accordingly, data will be selected after each 100 objects are inserted (atomically).

All tests have as main objective to determine the performance degradation of Core Data in relation to the amount of persisted data and the number of relationships between the data entities.

The next post will present our results and conclusions, stay tuned!

This post is also available in Portuguese: Testes de performance do Core Data sobre SQLite – Parte 1