Chapters
Chapters

Chapters

Hide chapters

Core Data by Tutorials

Eighth Edition · iOS 14 · Swift 5.3 · Xcode 12

Before You Begin

Section 0: 5 chapters
Show chapters Hide chapters

Core Data by Tutorials

Section 1: 11 chapters
Show chapters Hide chapters

8. Measuring & Boosting Performance
Written by Matthew Morey

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In many ways, it’s a no-brainer: You should strive to optimize the performance of any app you develop. An app with poor performance will, at best, receive bad reviews and, at worst, become unresponsive and crash.

This is no less true of apps that use Core Data. Luckily, most implementations of Core Data are fast and light already, due to Core Data’s built-in optimizations, such as faulting.

However, the flexibility that makes Core Data a great tool means you can use it in ways that negatively impact performance. From poor choices in setting up the data model to inefficient fetching and searching, there are many opportunities for Core Data to slow down your app.

You’ll begin the chapter with an app that’s a slow-working memory hog. By the end of the chapter, you’ll have an app that’s light and fast, and you’ll know exactly where to look and what to do if you find yourself with your own heavy, sluggish app — and how to avoid that situation in the first place!

Getting started

As with most things, performance is a balance between memory and speed. Your app’s Core Data model objects can exist in two places: in random access memory (RAM) or on disk.

Accessing data in RAM is much faster than accessing data on disk, but devices have much less RAM than disk space.

iOS devices, in particular, have less available RAM, which prevents you from loading tons of data into memory. With fewer model objects in RAM, your app’s operations will be slower due to frequent slow disk access. As you load more model objects into RAM, your app will probably feel more responsive, but you can’t starve out other apps or the OS will terminate your app!

The starter project

The starter project, EmployeeDirectory, is a tab bar-based app full of employee information. It’s like the Contacts app, but for a single fictional company.

Measure, change, verify

Instead of guessing where your performance bottlenecks are, you can save yourself time and effort by first measuring your app’s performance in targeted ways. Xcode provides tools just for this purpose.

Measuring the problem

Build, run, and wait for the app to launch. Once it does, use the Memory Report to view how much RAM the app is using.

Exploring the data source

In Xcode, open the project navigator and click on EmployeeDirectory.xcdatamodeld to view the data model. The model for the starter project consists of an Employee entity with 11 attributes and a Sale entity with two attributes.

Making changes to improve performance

The likely culprit for the high memory usage is the employee profile picture. Since the picture is stored as a binary data attribute, Core Data will allocate memory and load the entire picture when you access an employee record — even if you only need to access the employee’s name or email address!

Verify the changes

Now that you’ve made all the necessary changes to the project, it’s time to see if you actually improved the app.

Fetching and performance

Core Data is the keeper of your app’s data. Anytime you want to access the data, you have to retrieve it with a fetch request.

Fetch batch size

Core Data fetch requests include the fetchBatchSize property, which makes it easy to fetch just enough data, but not too much.

Measuring the problem

You’ll use the Instruments tool to analyze where the fetch operations are in your app.

Changes to improve performance

Open EmployeeListViewController.swift and find the following line of code in employeeFetchRequest(_:):

Verify the changes

Now that you’ve made the necessary change to the project, it’s once again time to see if you’ve actually improved the app.

Advanced fetching

Fetch requests use predicates to limit the amount of data returned. As mentioned above, for optimal performance, you should limit the amount of data you fetch to the minimum needed: the more data you fetch, the longer the fetch will take.

Measure the problem

Instead of Instruments, you’ll use the XCTest framework to measure the performance of the department list screen. XCTest is usually used for unit tests, but it also contains useful tools for testing performance.

Changes to improve performance

The current implementation of totalEmployeesPerDepartment uses a fetch request to iterate through all employee records. Remember the very first optimization in this chapter, where you split out the full-size photo into a separate entity? There’s a similar issue here: Core Data loads the entire employee record, but all you really need is a count of employees by department.

Verify the changes

Now that you’ve made all the necessary changes to the project, it’s once again time to see if you’ve improved the app’s performance.

Fetching counts

As you’ve already seen, your app doesn’t always need all information from your Core Data objects; some screens simply need the counts of objects that have certain attributes.

Measure the problem

You’ll use XCTest again to measure the performance of the employee detail screen.

Changes to improve performance

In the previous example, you used NSExpression to group the data and provide a count of employees by department instead of returning the actual records themselves. You’ll do the same thing here.

Verify the changes

Now that you’ve made the necessary changes to the project, it’s once again time to see if you’ve improved the app. Open EmployeeDetailViewControllerTests.swift and add a new function to test the salesCountForEmployeeFast function you just created.

Using relationships

The code above is fast, but the faster method still seems like a lot of work. You have to create a fetch request, create a predicate, get a reference to the context, execute the fetch request and get the results out.

Challenge

Using the techniques you just learned, try to improve the performance of the DepartmentDetailsViewController class. Don’t forget to write tests to measure the before and after execution times. As a hint, there are many methods that provide counts, rather than the full records; these can probably be optimized somehow to avoid loading the contents of the records.

Key points

  • Most implementations of Core Data are fast and light already, due to Core Data’s built-in optimizations, such as faulting.
  • When making improvements to Core Data performance you should measure, make targeted changes and then measure again to validate your changes had the intended impact.
  • Small changes to the data model, such as moving large binary blobs to other entities, can improve performance.
  • For optimal performance, you should limit the amount of data you fetch to the minimum needed: the more data you fetch, the longer the fetch will take.
  • Performance is a balance between memory and speed. When using Core Data in your apps, always keep this balance in mind.
7. Unit Testing
9. Multiple Managed Object Contexts
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now