Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
  • Overview
  • Transcript

2.8 Performance Considerations

Since Core Data is very powerful, it can naturally have an impact on performance. If you don’t pay attention to performance as you build your app, you might run into bottlenecks. In this lesson, I’ll give you some tips on how to avoid common performance pitfalls with Core Data.

Related Links

2.8 Performance Considerations

Hi, and welcome back to Get Started with Core Data. In this lesson, I want to talk a little bit about performance considerations. As you know, I have chosen to use multiple fetched results controllers in our project application. But normally, you should avoid using them whenever possible, cuz they're expensive to use. As with every optimization though, you shouldn't prematurely do it. If you don't experience performance problems in your case, it's no issue. Instead of using fetch requests, you could use ordered relationships like I have shown you with the quiz and questions. Of course, it isn't so convenient as using a fetch results controller if you have a lot of changing parts and need to do a lot of faulting and refreshing. If you have an object like a locked in user that is frequently accessed, try to make a single node out of it and don't fetch it every time. If you do have to use fetch requests, you also need to consider a few things. If you need to do sorting, do it with core data, meaning you should use sort descriptors. You should also set an index on every attribute that is sortable. If, like we do in the question table view controller, you will most certainly access every or most of the entities, it is a good idea to materialize there objects right away. To do that, you can set return objects as faults to false under fetch requests. If you have a lot of objects, you probably shouldn't initialize all of them right away, let's fetch the data when needed. If your data doesn't changed too often, you can consider using a cache. Here I'm creating a dynamic name for a cache since we need a different query by request. I'm using a unique object id for this which is provided by core data. This is probably not the best use case for caching, since you could potentially end up with a lot of different caches. But I just wanted to show an example. If you don't use fetch results controllers like we do here, you could also prefetch related entities. For instance, we could fetch the questions to each quiz in your overview right away. An example use case would be a fetch for employees where you want to also fetch the departments they work in. You can prefetch it by using a relationship key path or prefetching. Considering the data model, there are also a few points to remember. You might be tempted to cleanly divide all your data up into separate entities. For instance, you could create different question types as entities, like I mentioned before. But the fewer entities you have the better, even if that means some attributes are empty. You should also avoid one to one relationships, since one entity can be embedded into the other. This was a quick overview of the most important points you can use to improve through performance of your application. Of course, you can do much more but that is out of the scope of this course. In the next lesson, we will look at what to do when your data model changes after you already released your application. See you there.

Back to the top