#ios #macos #core-data #nsfetchedresultscontroller
#iOS #macos #core-данные #nsfetchedresultscontroller
Вопрос:
Я, конечно, прочитал документ, но я не совсем понимаю смысл «настройки любых разделов и упорядочения содержимого».
- Разве такая информация не поступает из базы данных?
- Означает ли это
NSFetchedResultsController, что помимо индексов базы данных нужны какие-то другие типы индексов? - Что на самом деле происходит при
NSFetchedResultsControllerнастройке кэша? - Полезен ли кэш только для статических данных? Если мои данные часто обновляются, должен ли я использовать кеш или нет?
- Как я могу профилировать производительность кэша? Я попробовал кэш, но не смог увидеть никакого улучшения производительности. Я рассчитал время
-performFetch:, но увидел увеличение времени с 0,018 с (без кэша) до 0,023 с (с кэшем). Я также-objectAtIndexPath:рассчитал время и уменьшил его только с 0,000030 (без кэша) до 0,000029 (с уловом).
Другими словами, я хочу знать, когда кэш повышает (или не повышает) производительность и почему.
Как указал @Marcus ниже, «500 записей — это крошечно. Core Data может справиться с этим без заметного отставания от человека. Кэширование используется, когда у вас есть десятки тысяч записей. » Поэтому я думаю, что есть несколько приложений, которые выиграли бы от использования кэша.
Ответ №1:
Кэш для NSFetchedResultsController — это своего рода короткий путь. Это кэш последних результатов из NSFetchRequest . Это не все данные, а достаточно данных для NSFetchedResultsController быстрого отображения результатов; очень быстро.
Это «копия» данных из базы данных, которая сериализуется на диск в формате, который легко используется NSFetchedResultsController при следующем создании экземпляра.
Чтобы посмотреть на это по-другому, это последние результаты, замороженные на диске.
Комментарии:
1. Спасибо, @Marcus. Если мои данные часто обновляются, должен ли я использовать кеш или нет?
2. Я бы использовал кеш, если вы не собираетесь часто менять предикат.
3. Я попробовал кэш, но не смог увидеть никакого улучшения производительности. Как я могу профилировать производительность кэша? Я синхронизировал -выполнил выборку: но увидел увеличение времени с 0,018 с (без кэша) до 0,023 с (с кэшем). Я также timed -objectAtIndexPath: и только уменьшение времени с 0,000030 (без кэша) до 0,000029 (с уловом).
4. Кэш улучшит производительность только при втором запуске (при первом запуске вы создаете кеш). Кроме того, преимущество кэша будет ощущаться только в том случае, если ваша выборка без него занимает у человека заметное количество времени. Ваш текущий набор данных слишком мал, чтобы получить улучшение. Попробуйте загрузить тест с на порядок большим количеством данных, чем вы ожидаете от приложения, а затем посмотрите производительность.
5. 500 записей — это крошечно . Core Data может справиться с этим без заметного отставания от человека. Кэширование используется, когда у вас есть десятки тысяч записей. Поиск оптимизаций — это то, что вы делаете после того, как найдете точку доступа, иначе это потраченные впустую усилия.
Ответ №2:
Из документации NSFetchedResultsController :
Там, где это возможно, контроллер использует кэш, чтобы избежать необходимости повторять работу, выполняемую при настройке любых разделов и упорядочении содержимого
Чтобы воспользоваться преимуществами кэша, вы должны использовать разделение или упорядочение ваших данных.
Так что, если initWithFetchRequest:managedObjectContext:sectionNameKeyPath:cacheName: вы установите sectionNameKeyPath nil значение, вы, вероятно, не заметите никакого прироста производительности.
Ответ №3:
Кэш Там, где это возможно, контроллер использует кэш, чтобы избежать необходимости повторять работу, выполняемую при настройке любых разделов и упорядочении содержимого. Кэш поддерживается при запуске вашего приложения.
При инициализации экземпляра NSFetchedResultsController обычно указывается имя кэша. (Если вы не укажете имя кэша, контроллер не кэширует данные.) Когда вы создаете контроллер, он ищет существующий кэш с заданным именем:
Если контроллер не может найти подходящий кэш, он вычисляет требуемые разделы и порядок объектов внутри разделов. Затем он записывает эту информацию на диск.
Если он находит кэш с тем же именем, контроллер проверяет кэш, чтобы определить, является ли его содержимое по-прежнему действительным. Контроллер сравнивает текущее имя объекта, хэш версии объекта, дескрипторы сортировки и путь к ключу раздела с теми, которые хранятся в кэше, а также дату изменения файла кэшированной информации и файла постоянного хранилища.
Если кэш соответствует текущей информации, контроллер повторно использует ранее вычисленную информацию.
Если кэш не соответствует текущей информации, тогда требуемая информация пересчитывается, а кэш обновляется.
Каждый раз, когда изменяется раздел и информация о заказе, кэш обновляется.
Если у вас есть несколько выбранных контроллеров результатов с разными конфигурациями (разные дескрипторы сортировки и т. Д.), Вы должны присвоить каждому другое имя кэша.
Вы можете очистить кеш с помощью deleteCache(с именем:).