Последствия изменения производительности экземпляров NSManagedObject, которые я никогда не собираюсь сохранять - PullRequest
0 голосов
/ 16 октября 2011

У меня есть приложение на основе CoreData, которое извлекает данные о прошлых событиях из постоянного хранилища SQLite. Как только у меня есть прошедшие события, мое приложение выполняет некоторый статистический анализ, чтобы предсказать будущие события, основываясь на данных, которые он имеет о прошлых событиях. Как только мое приложение сделало прогноз о будущих событиях, я хочу запустить другой алгоритм, который выполняет некоторую оценку этого прогноза. Я ожидаю провести много таких оценок, поэтому оптимизация производительности для каждой оценки, вероятно, будет иметь решающее значение.

Теперь все классы, которые мне нужны для представления моих будущих прогнозов событий, существуют в моей модели данных, и у меня есть подклассы NSManagedObject для большинства важных объектов. Самым простым способом реализации моих алгоритмов является «заполнение» результатов будущих событий на основе прогноза, а затем выполнение моей оценки с использованием экземпляров NSManagedObject как для прошлых событий, так и для прогнозов будущих событий. Однако я обычно не хочу сохранять эти прогнозы будущих событий в своем постоянном хранилище: после того, как я выполнил свою оценку прогноза, я хочу отбросить прогнозы и просто сохранить результаты оценки. Думаю, я могу сделать это довольно легко, просто отправив сообщение rollback: в мой контекст управляемого объекта, как только моя оценка будет завершена.

Все это будет работать нормально, и с точки зрения кодирования, это будет довольно легко реализовать. Однако мне интересно, стоит ли ожидать проблем с производительностью при столь интенсивном использовании управляемых объектов, когда я не собираюсь когда-либо сохранять внесенные изменения. Учитывая, что производительность может быть фактором, имеет ли смысл использовать для этого экземпляры NSManagedObject? Конечно, все, что он делает, чтобы отслеживать изменения и поддерживать такие вещи, как отмена и сложные отношения сущностей, сопряжено с некоторыми накладными расходами. Должен ли я быть обеспокоен этими накладными расходами?

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

1 Ответ

2 голосов
/ 16 октября 2011

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

Основные данные не имеют накладных расходовчто люди ожидают благодаря его оптимизации.Как правило, использование управляемых объектов в памяти происходит так же быстро или быстрее, чем любые пользовательские объекты и код управления, которые вы пишете сами.

Должны ли меня беспокоить эти издержки?

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

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

Преждевременная оптимизация - корень всего зла.

...