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

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

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

7
core-data iphone

2 ответов

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

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

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

раздел производительности основных данных руководства может помочь вам план. Инструменты позволяет увидеть подробную информацию о производительности основных данных.

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

11

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

- (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% решение, но в большинстве случаев он будет делать работу...

3