Оптимальный способ сохранить граф объектов для прошивки на iPhone

У меня есть граф объектов в Objective-C на платформе iPhone, который я хочу сохранять при закрытии приложения. Граф имеет около 100-200 тысяч объектов и содержит много циклов (по задумке). Мне нужно иметь возможность читать/записывать этот график как можно быстрее.

До сих пор я пытался использовать NSCoder. Это не только борется с циклами, но также требует времени и значительного объема памяти для сохранения графа - возможно, потому, что XML-документ используется скрыто. Я также использовал базу данных SQLite, но просмотр такого количества строк также занимает значительное время.

Я рассматривал возможность использования Core-Data, но боюсь, что у меня возникнут те же проблемы, что и с SQLite или NSCoder, поскольку я считаю, что резервные хранилища для основных данных будут работать таким же образом.

Итак, есть ли какой-либо другой способ, которым я могу легко справиться с сохранением этого графа объектов - в идеале я хотел бы что-то вроде сериализации Java? Я думал попробовать Tokyo Cabinet или записать память, занятую кучей структур C, на диск - но это будет много работы по переписыванию.


person teabot    schedule 18.08.2009    source источник


Ответы (2)


Я бы рекомендовал переписать как c structs. Я знаю, что это будет больно, но запись на диск будет не только быстрой, но и должна работать намного лучше.

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

т.е. если ваш цикл постоянно выделяет объекты, это замедлит его работу. Если вы предварительно выделили 1000 структур и просто имеете массив указателей (или один указатель), то это происходит намного быстрее.

(У меня были ситуации, когда даже мой настольный Mac был слишком медленным и не имел достаточно памяти, чтобы справиться с этими миллионами объектов, создаваемых подряд)

person Jay    schedule 18.08.2009
comment
Пока вы не переносите файлы дампа с компьютера на компьютер, необработанный дамп памяти будет в порядке. Если вы пытаетесь поделиться файлом между разными машинами, у вас возникнут проблемы с порядком байтов. Это определенно лучше в ограниченных обстоятельствах. - person corydoras; 27.08.2009

Вместо того, чтобы создавать свои собственные, я настоятельно рекомендую еще раз взглянуть на Core Data. Core Data был разработан с нуля для сохраняющихся графов объектов. . Архив на основе NSCoder, подобный тому, который вы описываете, требует, чтобы у вас был весь граф объектов в памяти, а все записи были атомарными. Core Data переносит объекты в память и из памяти по мере необходимости и может записывать на диск только ту часть вашего графика, которая изменилась (через SQLite).

Если вы прочитали Руководство по программированию основных данных или их учебное руководство, можно увидеть, что они много думали об оптимизации производительности. Если вы будете следовать рекомендациям Apple (которые могут показаться нелогичными, например, их предложение денормализовать ваши структуры данных в некоторых точках), вы можете выжать из своей модели данных гораздо больше производительности, чем вы ожидаете. Я видел эталонные тесты, в которых Core Data ловко превзошла настроенный вручную SQLite для доступа к данным в базах данных того размера, на который вы смотрите.

На iPhone у вас также есть некоторые преимущества памяти при использовании управления размером пакета выборки и очень хороший вспомогательный класс в NSFetchedResultsController.

Создание проверенной реализации Core Data вашего графа для сравнения с вашими существующими методами хранения данных не займет много времени.

person Brad Larson    schedule 18.08.2009
comment
Это никогда не будет соответствовать той же производительности, что и массовая загрузка/выгрузка памяти, если это все, чего пытается достичь пользователь. - person corydoras; 27.08.2009
comment
Но это не все, что они пытаются сделать. Они пытаются управлять сложным графом объектов, включая сериализацию и десериализацию — случай, для которого Core Data идеально подходит. Кроме того, если все сделано правильно с использованием Core Data, весь граф из 100 000–200 000 элементов не нужно будет загружать в память сразу, что является огромным преимуществом для устройства с ограниченным объемом памяти, такого как iPhone. - person Brad Larson; 27.08.2009