Ok. This is the exact same question as here: Why is NSFetchedResultsController loading all rows when setting a fetch batch size?
But the solution for his doesn't solve for mine.
I have a screen that has several thousand records and is slow to load them all. I set the batch size to 30 (roughly three times the cells on the screen) and it still loops through and loads all the batches for some reason.
Here is the code
- (NSFetchedResultsController *)guestCardFetchedResultsController
{
if (guestCardFetchedResultsController != nil) {
return guestCardFetchedResultsController;
}
// SELECT * from GuestCard
NSFetchRequest* fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"GuestCard" inManagedObjectContext:self.context];
[fetchRequest setEntity:entity];
// ORDER BY updated DESC
NSSortDescriptor* updatedSortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@"created" ascending:NO];
[fetchRequest setSortDescriptors:@[updatedSortDescriptor]];
fetchRequest.fetchBatchSize = 30;
NSString *cacheName = self.isReportProblemView ? @"reportProblemGuestCardsAll" : @"guestCardsAll";
[NSFetchedResultsController deleteCacheWithName:cacheName];
NSFetchedResultsController *aFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:self.context sectionNameKeyPath:@"sectionIdentifier" cacheName:cacheName];
aFetchedResultsController.delegate = self;
self.guestCardFetchedResultsController = aFetchedResultsController;
// Clean up
NSError *error = nil;
if (![[self guestCardFetchedResultsController] performFetch:&error]) {
}
return self.guestCardFetchedResultsController;
}
I'm not doing anything terribly interesting in this scenario. Here's some of the delegate code (excluding the cell creating, which I confirmed only is called for the number of cells on screen):
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
if ([self.guestCardFetchedResultsController.fetchedObjects count] == 0) {
return 1;
}
// Return the number of sections.
return [[self.guestCardFetchedResultsController sections] count];
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
if ([self.guestCardFetchedResultsController.fetchedObjects count] == 0) {
return 1;
}
// Return the number of rows in the section.
id <NSFetchedResultsSectionInfo> sectionInfo = [guestCardFetchedResultsController sections][section];
return [sectionInfo numberOfObjects];
}
- (NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section
{
if ([self.guestCardFetchedResultsController.fetchedObjects count] == 0) {
return @"";
}
return [[self.guestCardFetchedResultsController sections][section] name];
}
After reading the docs on the NSFetchedResultsController initializer, I think the problem is that you have a sort in the fetch request (created) that doesn't naturally sort the same as the section key path (sectionIdentifier). The specific sentence in the docs I'm looking at says:
If this key path is not the same as that specified by the first sort
descriptor in fetchRequest, they must generate the same relative
orderings
I recommend modifying your fetch request to sort on sectionIdentifier first, then created. I think that'll fix your issue.
NSSortDescriptor* updatedSortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@"created" ascending:NO];
NSSortDescriptor* sectionSortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@"sectionIdentifier" ascending:NO];
// It's critical the sectionSortDescriptor is first
[fetchRequest setSortDescriptors:@[sectionSortDescriptor, updatedSortDescriptor]];
Note that if either the created or sectionIdentifier properties are actually methods on your entity class, that will definitely force Core Data to load all your data before it can sort/section, because it needs to execute that method on each entity first.
When using fetchBatchSize rather than returning the objects in an NSArray it returns a special batch faulting array. Although it does load in all the object IDs all the objects in the array are faults, meaning their data was not loaded, i.e. like a placeholder object. Then as you loop the array (or the table reload does) when access an object's property, it performs the database query for that object's properties including the next objects up to the fetchBatchSize (the minimum appears to be 4 by the way). The best way to debug this internal behaviour by seeing the queries is to edit your scheme and add a run argument:
-com.apple.CoreData.SQLDebug 1
That will output to console the various queries. You'll see the first query for the row IDs, then each batch loading of data.
So what you might be experiencing is it being slow to load in all the row IDs and creating the faulted objects, however that should be fast.
Another possibility is when it accesses the sectionIdentifier property to build the sections, that causes the object to be loaded in too, and thus causes all batches to load. To solve that you could try setting propertiesToFetch to include the sectionIdentifier, that way the first query should load in that property and then when it is accessed the object shouldn't be loaded in.
I've had the same question and in the end I concluded, that it works as it should.
When you set fetchBatchSize fetchRequest loads all data to cache because otherwise this parameter would be useless. I guess it's used for using data just after loading. But when you getting object as [fetchResultController objectAtIndexPath:indexPath] it is fulfilled by ManagedObjectContext (I suppose), not by fetchRequest.
So you can set fetchBatchSize to 0 and every time you access fault it will be requested from persistent store. Or you can set other value and also set fetchLimit and fetchOffset every time you scroll table view. But you still have to know overall objects number.
