Время, необходимое для извлечения основных данных с фильтрацией NSPredicates ~ WEIRD - PullRequest
1 голос
/ 08 февраля 2012

Итак, я пытаюсь получить около 2000 объектов из базовых данных и пытаюсь выяснить, какой из них был бы наиболее быстрым для их извлечения.

Без NSPredicates:

Когда я добавляю этот блок (ниже), оператор if занимает 90% от общего времени, необходимого для выполнения, что понятно, и поэтому я закомментирую его.

Block {

    NSError *error;
    NSManagedObjectContext *context =  <#Get the context#>;

    // The IF block

/*   if (![context save:&error])
    {
        NSLog(@"error %@", error);
    }
*/
       // The block above takes 90% of the total time of fetch

    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    NSEntityDescription *theEntity = [NSEntityDescription 
                                  entityForName:@"EntityName" inManagedObjectContext:context];

    [fetchRequest setEntity:theEntity];

    NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];    

    }

С предикатами NSP:

Я устанавливаю предикат как

NSPredicate *predicate = [NSPredicate predicateWithFormat:@"handle == %@",handle];

и выполняю ту же выборку, как показано в Block()

Видно, что общее время с точностью до наоборот - примерно на 90% быстрее, если я использую IF BLOCK ~ 6 секунд.

В противном случае, если этот блок прокомментирован, выборкаВремя много ~ 3 минуты.Это происходит только при установке predicate для fetchRequest.

Может кто-нибудь объяснить, пожалуйста?

То есть

 /*
 Save + straight fetch = slow, due to saving. 
 Straight fetch - pretty fast. 
 Predicate fetch, slow. 
 Save + predicate fetch, much faster? 
 */

Ответы [ 3 ]

2 голосов
/ 08 февраля 2012

. Без сохранения он должен извлекать данные из БД, а также из любых существующих объектов, которые могут иметь несохраненные изменения.

1 голос
/ 08 февраля 2012

Когда я пытаюсь понять внутреннюю работу Core Data, это помогает включить SQL Debug со следующим аргументом:

    -com.apple.CoreData.SQLDebug 1

Это выведет на экран все выполняемые операторы SQL, чтобы вы могли действительно увидеть разницу. Также возможно (просто теория), что сразу после сохранения постоянное хранилище (или, возможно, только индексы) все еще находится в кеше, что ускоряет выборку по индексу (предикату).

В любом случае, SQL Debug покажет вам, какие операторы выполняются и когда - может привести к некоторой оптимизации в вашей модели для индексации.

0 голосов
/ 08 февраля 2012

Повышение эффективности не имеет ничего общего с тем, как вы выполняете выборку.

Причина ваших задержек в том, что вы сохраняете в блоке if.Это довольно дорогая операция.Если вы делаете это 2000 раз, это может занять несколько секунд или даже больше.

Когда вы выбираете объекты из постоянного хранилища, сохранение не имеет смысла, только если вы должны были изменить эти объекты.И даже тогда вы попытаетесь сохранить свои звонки, чтобы сэкономить до минимума.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...