2010-01-23 2 views
2

У меня есть модель данных, которая вроде этого упрощенного рисунка:основные данные используют много памяти

alt text http://dl.dropbox.com/u/545670/thedatamodel.png

Это немного странно, но идея состоит в том, что приложение управляет несколько счетами/идентичности, которые человек может иметь в единой системе обмена сообщениями. Каждая учетная запись связана с одним пользователем в системе, и каждое сообщение может потенциально отображаться/отправляться нескольким учетным записям (но у них есть глобально уникальный идентификатор, следовательно, свойство messageID, которое используется при импорте для извлечения объектов сообщений, которые, возможно, уже были загружается и импортируется предыдущим сеансом).

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

fetch.fetchPredicate = [NSPredicate predicateWithFormat:@"%@ IN accounts", theAccount]; 
    fetch.sortDescriptors = [NSArray arrayWithObject:[[NSSortDescriptor alloc] initWithKey:@"date" ascending:NO]]; 
    fetch.fetchLimit = 20; 

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

В любом случае, после всей этой установки большая проблема заключается в том, что использование памяти кажется немного сумасшедшим. Когда я настраиваю тестовый пример, когда он импортирует сотни сообщений в систему и периодически повторно извлекает (используя извлечение, упомянутое выше) и показывает их в списке (только последние 20 ссылаются на список), память просто сходит с ума , 60MB .. 70MB ... 100MB .. и т. Д.

Я отследил его до отношения «многие ко многим» между учетной записью и сообщением. Даже при сборе мусора управляемые объекты по-прежнему сильно ссылаются на свойство отношений сообщений в учетной записи. Я знаю это, потому что я помещаю журнал в финализацию моего экземпляра Message и никогда его не вижу - но если я периодически перезагружаю контекст или обновляю объект: mergeChanges: в объекте учетной записи я вижу, что сообщения о завершении и использование памяти остаются довольно последовательными (хотя все еще несколько растет, но учитывая, что я импортирую материал, этого можно ожидать). Проблема в том, что я не могу полностью переустановить контекст или объект учетной записи все время, потому что это действительно мешает наблюдателям, которые наблюдают другие атрибуты объекта учетной записи!

Я мог бы просто моделировать это неправильно или думать об этом неправильно, но я постоянно читаю о том, что важно, чтобы Core Data рассматривал как объектный график, а не базу данных. Я думаю, что я сделал это здесь, но, похоже, это вызывает проблемы. Что мне делать?

ответ

2

Используйте инструмент Object Graph. Он расскажет вам все владельцы, сохраняющие объект в живых.

1

Вы прочитали section of the docs on this topic?

+0

Да. Я считаю, что у меня есть настройка материала в соответствии с руководством. Я даже запускаю пакеты импорта на другой поток с их собственными контекстами сейчас, и он все еще продолжает расти. :( – Sean

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