2010-12-13 2 views
3

Это на iOS.Ускорение загрузки основных данных

У меня есть база данных ядра с около 350 000 объектов. Объекты (Продукт) имеют два свойства: «Штрих-код» и «Обозначение». Пользователь может искать объект, ища «Штрих-код», и «Обозначение» должно быть возвращено. Все работает нормально, за исключением медленных. Код, который я использую:

NSEntityDescription *_product = [NSEntityDescription entityForName:@"Product" inManagedObjectContext:importContext]; 
NSFetchRequest *fetch = [[NSFetchRequest alloc]init]; 

[fetch setEntity:_product]; 
[fetch setPredicate:[NSPredicate predicateWithFormat:@"Barcode == %@",theBarcode]]; 

NSError *error = nil; 
NSArray *results = [importContext executeFetchRequest:fetch error:&error]; 

NSManagedObject *object = [results objectAtIndex:0]; 

Так как я только хочу, чтобы принести один объект, есть способ ускорить его?

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

Заранее благодарен!

EDIT: Я добавил [fetch setFetchLimit: 1]; которые ускоряют его немного. Но скорость становится все медленнее в базе данных объекта.

+0

просто хочу спросить (может быть, это поможет), почему вы загружаете все данные в массив при каждом запуске? – shannoga

+0

Я этого не делаю. Но я сказал, что если я это сделаю, то у меня будет медленный запуск :) – Mikael

ответ

7

Атрибут Barcode проиндексирован?

+0

Спасибо! Это решило мою проблему очень приятно! Я на самом деле думал об индексировании по дороге домой с работы в пятницу, но потом это были выходные, и я полностью забыл об этом :) Еще раз спасибо! – Mikael

4

Во-первых, как писал @paulbailey, проверьте, проиндексирован ли индекс Barcode.

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

CoreData предоставляет вам много объектно-ориентированных средств с постоянством на диске, но, конечно же, он имеет штраф.

Возможно, вам лучше всего отказаться от CoreData и использовать sqLite напрямую. Для этого есть приятная легкая обломок Objective-C под названием FMDB, см. here.

Если вы хотите придерживаться CoreData, один из способов улучшить ситуацию - это извлечь фоновый поток и показать результат в основном потоке, как описано в this Apple document. Таким образом, пользовательский интерфейс не замерзает при поиске базы данных.

+0

Да, на самом деле я начал проект с помощью FMDB, но вместо этого использовал Core Data. Я сделал это, потому что в будущем может появиться дополнительная информация для приложения. – Mikael

+0

и индексирование работало, как сказал @paulbailey. Это хорошо! Я часто забываю индексировать свойства CoreData: p – Yuji

0

Причина, по которой требуется больше времени на базу данных объекта, является то, что Core Data использует довольно скучный алгоритм поиска, который просто помещает указатель на первый объект, понимает его значение для searchitem, помещает указатель в следующий и один до сравнения.

Существует множество алгоритмов поиска, которые вы можете использовать в зависимости от вашей базы данных (отсортированные/не отсортированные списки, древовидная структура и т. Д.), Вы можете использовать Quicksearch, Hashsearches, treeearch и т. Д.

Возможно, вы также подумаете о создании базы данных SQlite, которая имеет некоторые хорошие рамки с интеллектуальными алгоритмами поиска.

Смежные вопросы