0
votes

Does it hurt to execute an NSFetchRequest that retrieves a lot of objects, maybe around 3 ~ 5K? I understand Core Data uses something called 'faulting' that ensures objects are not in memory until they are actually needed. So if I fetch 5K objects in an NSArray, that means the objects are really just placeholders until I actually access their properties? Is this a bad practice?

1
Core Data is highly optimized; I don't think that's where you'll run into trouble. The question you should always ask is why do you need 5k objects in memory at the same time? Can the user interact with that many? If you need to process them all, can you sequentialize? Etc. - Rayfleck
Not at all; the user will only interact with them one at a time. The problem is that I need to shuffle them. As far as I know, there's no way to do a "random fetch request", so I thought I'd just fetch them all, then do my own shuffling. - Rits
How are you fetching them - is there an index or anything that has a known range? You could randomize over that range to generate a random fetch. - Rayfleck
Yeah I could use a sort descriptor and set a random fetchOffset every time, but I also need the guarantee that no object is being interacted with twice. I could keep track of all fetchOffsets I have used, but eventually that too will become an array of 3K ~ 5K objects. - Rits
If a fetchOffset is an int or long, then 5k is not a big deal. Otherwise, you could update the core data row with "hasInteracted"=TRUE, and if you get a TRUE, fetch the next random one. Or, you could delete each one after you get it, or move it to another table, depending on whether you can regenerate your data easily when you have to start over. - Rayfleck

1 Answers

1
votes

Core Data is highly optimized and should be able to handle 3-5k objects. You'll need to determine empirically how this affects the run-time memory consumption of your app.