Результаты запроса ограничения области

Я новичок в Realm, и я уже видел этот ответ об ограничении запросов области (во многих других местах слишком).

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

RLMResults* rlm = [[Item class] objectsWithPredicate:predicate]; // this loads fast
NSArray* results = [rlm valueForKey:@"self"]; // this is slow

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

RLMResults* rlm = [[Item class] objectsWithPredicate:predicate]; // this loads fast
NSMutableArray* results = [@[] mutableCopy];

for (NSInteger i = 0; i < 5; i++) {
    Item* item = rlm[i]; // only the first call (when i == 0) is slow here
    [results addObject:item];
}

так что интересно здесь то, что только первый вызов rlm[i] (rlm[0]) занимает много времени, а затем (когда i > 0) вызов работает быстро.

Я делаю что-то неправильно? или есть ли способ ускорить загрузку большого объема данных или ограничить результаты?

Большое спасибо!


person J. Doe    schedule 19.05.2016    source источник


Ответы (1)


Как сказано в документации Realm, содержимое RLMResults загружается отложенно. Он создан, чтобы попытаться отложить «предварительную загрузку» чего-либо до тех пор, пока это не станет абсолютно необходимым. Когда вы перебираете каждый объект и добавляете его в NSArray, это заставляет каждый объект загружаться лениво, что (по понятным причинам) приведет к снижению производительности. Вероятно также, что большая часть предикатного запроса также выполняется лениво, поэтому производительность снижается при доступе к первому объекту в наборе результатов, а не при создании объекта RLMResults.

Если вы считаете, что снижение производительности из-за этого неприемлемо, вы можете попробовать другой подход к этому. Например, вместо копирования объектов в NSArray используйте объект RLMResults и отслеживайте только нужные объекты с помощью объекта NSRange. Кроме того, поскольку медленная только начальная загрузка, я также предлагаю вам попробовать оптимизировать запрос предиката, например, убедиться, что каждое свойство, по которому вы ищете, помечено как проиндексированное.

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

Я надеюсь, что это помогло!

person TiM    schedule 24.05.2016
comment
Спасибо за ответ, я не думаю, что использование RLMResults сработает (также не нашел ни одного примера его использования), и если у Realm действительно нет другого способа ограничить результаты (пока?), Оптимизация предикатного запроса (не всегда возможно) И заставить его загружаться в фоновом потоке было для меня единственным способом сделать это быстрее и не заморозить пользовательский интерфейс. - person J. Doe; 30.05.2016
comment
Пожалуйста! На странице документации Realm есть несколько примеров и объяснений RLMResults (особенно по запросам: realm.io /docs/objc/latest/#queries), а также пример кода. Добавление ограничивающих функций уже обсуждалось ранее (github.com/realm/realm-cocoa /issues/2608), но было решено, что нет никакой реальной причины добавлять такой жесткий механизм, поскольку это не имеет смысла с реализацией отложенной загрузки Realm (это просто вопрос не перебирая каждый объект, возвращаемый в RLMResults. :) ). Прохладный! Удачи! - person TiM; 31.05.2016
comment
Так что на самом деле нет возможного предела, тогда я отмечу это как ответ;) - person J. Doe; 31.05.2016
comment
Итак, просто чтобы уточнить... нет необходимости разбивать на страницы, потому что ленивая загрузка достаточно эффективна? - person Jules Lee; 07.09.2019
comment
Это правильно! Realm только лениво загружает свойства, к которым вы в конечном итоге обращаетесь, а те, к которым вы обращались в прошлом, автоматически освобождаются с течением времени. Таким образом, обычно нет необходимости выполнять какую-либо логику разбиения на страницы для длинных результатов запроса. - person TiM; 08.09.2019