я проблемы с iOS-приложением на основе CoreData, когда оно пытается создать исходную БД из данных, отправленных с сервера. По сути, сервер отправляет фрагменты объектов размером 1 МБ (около 3000 на фрагмент), а клиент iOS десериализует их и записывает на диск.

Я вижу, что у первых 8 блоков (из 44) все идет довольно хорошо, затем производительность резко падает, и каждый блок начинает занимать все больше и больше времени, как показано на рисунке ниже. Практически все время потребляется в[NSManagedObjectContext save] как вы можете видеть из данных профилирования Instruments, но также кажется, что приложение по какой-то причине перестает работать на 100% CPU, например, оно ожидает дискового ввода-вывода или чего-то еще.

Несколько важных фактов о том, как я это делаю:

Каждый кусок обрабатывается по-своемуNSManagedObjectContext со своимNSAutoreleasePool, таким образом, между обработкой фрагментов не происходит наращивание объекта в незагруженном контексте.

Здесь нетNSUndoManager установить в любом из контекстов.

Здесь нетmergeChangesFromContextDidSaveNotification: происходит (то есть контексты чанка не помещают свои изменения в «основной» контекст)

Я использую хранилище данных на базе SQLite на iOS 4.3.

Записываемые записи имеют индексы.

Все задание синхронизации обрабатывается в одном фоновом потоке GCD (т.е.dispatch_queue_create() а такжеdispatch_async()).

Я понятия не имею, почему производительность внезапно падает, или что можно сделать для ее решения. Я осмотрелся и прочитал следующее, но ничего еще не выскочило на меня:

http://cocoawithlove.com/2008/03/testing-core-data-with-very-big.html

Зависит ли эффективность сохранения ManagedObjectContext от количества содержащихся (неизмененных) объектов?

Будем весьма благодарны за любые идеи или указания по масштабированию этого приложения до 100 000 записей в базе данных.

Edit - дополнительная статистика

Этот график инструментов показывает ту же симуляцию, что и выше (на iPad2), но включает в себя статистику активности диска, и вы можете довольно ясно увидеть, что все время «не работает на 100% ЦП», похоже, занято записью на диск.

Я также запустил ту же попытку синхронизации на симуляторе iOS. Общее использование памяти является более или менее постоянным для каждого чанка, за исключением словаря, который содержит идентификаторы объектов, которые со временем немного растут (но это не объекты CoreData или что-либо, что может повлиять на сохранение, это просто номера NSN). Это диктует небольшой объем памяти по сравнению с общей кучей, поэтому проблема не исчерпывается памятью.

Что интересно в этом тесте, так это то, что инструмент CoreData Save сообщает, что последующие сохранения занимают примерно столько же времени, что, очевидно, противоречит информации о профилировании ЦП из первого набора результатов. Кажется, что CoreData думает, что на внесение изменений в БД уходит столько же времени, но сама БД (т. Е. SQLite) внезапно требует гораздо больше времени для фактической передачи этих изменений на диск.