Производительность CoreData по сохранению контекста

Question

Я закончил преобразование своего приложения в слой CoreData для небольшого хранилища данных, которое я хочу использовать. У меня есть некоторые опасения по поводу производительности и как лучше всего ее использовать. Особенно: У меня много прогонов, где я читаю из атрибутов диска в файлах: каждый атрибут должен генерировать новый объект, если только объект такого типа и этого значения уже существует. Итак, для каждого файла, который я читаю, я: выполняю выборку, чтобы проверить, существует ли этот управляемый объект; если да, закончить, в противном случае я создаю объект, присваиваю значение и сохраняю контекст.

В настоящее время я сохраняю контекст один раз для каждого нового объекта, так что это происходит более или менее десять раз (для десяти атрибутов) для каждого прочитанного файла (который может быть сотен). Было бы лучше уменьшить точки сохранения контекста, возможно, один раз для файла, а не один раз для атрибута? Я не знаю накладных расходов на эту операцию, поэтому я не знаю, нормально ли это делать так часто, или как узнать время, потраченное на это (может быть, с инструментами? Не знаю, как). *

Answer 1

Нет необходимости сохранять после установки каждого атрибута.

Как правило, вы сохраняете управляемый объект только тогда, когда с ним выполнен код, поскольку сохранение сбрасывает отмену. В описанной вами настройке вы можете безопасно создавать сотни управляемых объектов, прежде чем сохранять их в постоянном хранилище. Вы можете хранить в памяти большое количество (тысячи) легких (текстовых атрибутов) объектов, не напрягая iPhone.

Единственная проблема на iPhone заключается в том, что вы никогда не знаете, когда приложение будет приостановлено или закрыто. Это делает сохранение более распространенным, чем на других платформах. Тем не менее, не в той степени, которую вы сейчас используете.

Раздел «Основные данные производительности» руководства может помочь при планировании. Инструменты позволяет вам увидеть детали производительности Core Data.

Однако я бы ничего не сделал, пока вы не протестировали приложение с большим количеством данных и обнаружили, что оно работает медленно. Преждевременная оптимизация является источником всего зла. Не тратьте время на попытки предотвратить проблему, которой у вас может не быть.

Answer 2

Чтобы предотвратить проблему «внезапной остановки приложения», вы можете реализовать что-то вроде этого метода:

- (void)saveContext {

NSError *error = nil;
NSManagedObjectContext *managedObjectContext = self.managedObjectContext;


if (managedObjectContext != nil) {
    if ([managedObjectContext hasChanges] && ![managedObjectContext save:&error]) {
        /*
         Replace this implementation with code to handle the error appropriately.

         abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development. If it is not possible to recover from the error, display an alert panel that instructs the user to quit the application by pressing the Home button.
         */
        LogError(@"Unresolved error %@, %@", error, [error userInfo]);
            // abort();
    } 
}

}

и используйте его внутри двух методов делегата приложения:

- (void)applicationWillTerminate:(UIApplication *)application;

и

- (void)applicationDidEnterBackground:(UIApplication *)application;

Думал, что это может быть не 100% решение, но в большинстве случаев он будет работать ...