slow-loading persistent store coordinator in core data

0
votes

I have been developing a Cocoa app with Core Data. Initially everything seemed fine, but as I added data to the application, I found that the initial data window took ages to load. To fix that, I moved to another startup window that didn't have the data, so start-up was snappy. However, no matter what I do, my first fetch AND my first attempt to load a data window (with tables views) are always slow. (That is, if I fetch slowly and then ask for the data window, both will be slow the first time around.) After that, performance is acceptable.

I traced through my application and found that while I can quickly step through the program, no matter what, the step that retrieves the persistent store coordinator is incredibly slow ... 15 - 20 seconds can elapse with a spinning beach ball.

I've read elsewhere that I might want to denormalize the data. I don't think that will be sufficient. An earlier version was far less "interconnected" between the entities, and it still was a slug at startup. Now I'm looking at entities that may have as high as 18,000 managed objects. Some of the relations are essential to having the data work correctly.

I've also read about the option of employing a separate managed object context in the background. The problem with this is that even this background context would take too long to be usable. If the user tries to run a search, he or she will still be waiting forever for that context to load. I might buy myself a few seconds while the user decides what to type in to the search field, but I can't afford to stall for 25 seconds.

I noticed that once data is imported into the persistent store, even searches on a table that is not related to others (and only has 1000 objects) still takes ages to load. The reason seems to be that it's the coordinator retrieval itself that's slow, not the actual fetch or the context.

Can anyone point me in the right direction on how to resolve this? Thanks!

2
performancecore-dataloadingnspersistentstore
18,000 is not big... it's actually very small as core data goes... Unfortunately, you have not given near enough information. Loading a PSC could involve many things, like migration and such. Also, a fetch has nothing to do with the initial creation of the PSC, so I am confused as to why you intermingle the PSC and the fetch. Maybe if you showed some code, along with which parts of the code are going away for that long it would help. Otherwise, any answer you get will be pure speculation. - Jody Hagins
Agree with Jody. You have to ask a more specific question. If your thesis is correct and it is the PSC, please amend the question to show how you create it. - Mundi
Opening the store accesses the file system synchronously. If you can help it don't open the store from the main queue. - quellish
The store that I created was the default store. Initially I used XML store type but that was way too slow. Using SQL store type helped, but not enough. - wdchild
Same problem unsolved here, although my app has only 50 records and takes up to 7 seconds to load. - MLBDG

2 Answers

0
votes

Before you create your data model:

If you’re storing large objects such as photos, audio or video, you need to be very careful with your model design.

The key point to remember is that when you bring a managed object into a context, you’re bringing all of its data into memory.

If large photos are within managed objects cut from the same entity that drives a table-view, performance will suffer. Even if you’re using a fetched results controller, you could still be loading over a dozen high-resolution images at once, which isn’t going to be instant.

To get around this issue, attributes that will hold large objects should be split off into a related entity. This way the large objects can remain in the persistent store and can be represented by a fault instead, until they really are needed.

If you need to display photos in a table view, you should use auto-generated thumbnail images instead.

Read the whole article

0
votes

You might be getting ahead of yourself thinking PSC is the culprit. There is more going on behind the scenes with CoreData than is readily obvious -- PSC is very flexible and must be directed.
A realistic approach for the data size you specified (18K) is to focus on modularizing the logic of your fetch request templates and validation for specific size cases (think small medium large XtraLarge, etc.).

The suggestion to denormalize your data does not take into account the overhead to get your data into a fully denormalized state, plus a (sometimes) unintended side-effect of denormalization is sparsity (unless you have very specific model of course).

Since you usually do not know beforehand what data will be accessed and modified beforehand, make a one-to-many relationship between your central task and any subtasks. This will free up some constraints on your data access.

You can always give your end users the option to choose how they want to handle the larger datasets.