Кодирование графов больших объектов с использованием NSKeyedArchiver ест память - PullRequest
0 голосов
/ 15 февраля 2010

Я использую NSKeyedArchiver для кодирования большого графа объектов (76295 объектов.) Это занимает много времени, но еще хуже, NSKeyedArchiver не возвращает всю свою память.

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

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

У вас есть предложения, которые мне могут понравиться?

P.S. База данных (sqlite) или CoreData не являются альтернативами, потому что кажется, что они очень плохо масштабируются с большим графом объектов, подобным упомянутому выше.

Я бы предпочел решение, использующее NSKeyedArchiver

Ответы [ 2 ]

1 голос
/ 15 февраля 2010

NSKeyedArchiver фактически не кодирует объекты. Он просто просматривает график и вызывает методы кодирования каждого экземпляра в графе. Поэтому наиболее вероятный источник утечки находится внутри пользовательского метода кодера, который вы написали для архивирования одного из ваших пользовательских классов. Возможно, вы захотите сделать тестовые архивы отдельных классов, чтобы проверить, не утек ли один из них.

Проблема с использованием NSKeyedArchiver для архивирования большого сложного графа состоит в том, что весь граф помещается в память одновременно. Одна утечка в одном кодере классов может взорваться, если много экземпляров этого класса заархивировано. Если у вас более 76 000 объектов и всего несколько тысяч утечек по несколько байт каждый, это будет происходить в спешке.

Я должен добавить, что я никогда не сталкивался и даже не читал о ситуации, в которой Базовые данные не работали лучше, чем архив для сложных графиков, независимо от их размера. Базовые данные были созданы специально для решения именно такой проблемы.

Если вы пробовали Core Data, и он застрял, возможно, это потому, что вы привыкли к наследованию объектов. Поскольку базовые данные используют наследование одной таблицы на стороне хранилища в SQL, все потомки сущности оказываются в одной и той же таблице, что приводит к затруднениям. Помните, сущности отделены от классов, которые они моделируют, поэтому вы можете иметь наследование классов без наследования сущностей. Это дает вам преимущества наследования в коде без потери скорости наследования объектов.

0 голосов
/ 24 марта 2010

Кажется, память возвращается системе медленно через более поздний интервал. Так что никакой реальной утечки памяти здесь нет.

Для всех остальных: попробуйте взглянуть на CoreData или sqlite3 напрямую. Если вы используете sqlite3 напрямую, убедитесь, что вы инкапсулировали полный набор запросов в транзакции; это значительно увеличит пропускную способность.

Подробнее об оптимизации скорости sqlite: http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html

...