Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Since you explain (in a comment) that all the attributes are strings, you may have a hard time improving the situation. You're doing a <strong>lot</strong> of string comparisons in that fetch-- 46k records multiplied by at least 3 for the first two predicates, plus more depending on how many <code>stories</code> relationships there are on average. That's the main reason for your performance issues-- doing that many string comparisons is going to be a bottleneck.</p> <p>A couple of things that may help:</p> <ul> <li>In the third predicate you're looking at <code>@"(ANY stories.permission.owner_person_uid == %@ OR stories.@count == 0)"</code>. Predicates are evaluated left to right. Numeric comparisons are faster than string comparisons, so put the <code>@count</code> check first. If it's true then the second half won't need to be evaluated, and you'll skip a whole lot of string comparisons.</li> <li>The left-to-right thing also applies to the order of your <code>NSPredicate</code> instances. You probably have some idea what the data looks like-- make sure that the <strong>most restrictive</strong> predicate (i.e. the one that the largest number of objects will <em>not</em> pass) is the first one in the list. Then the second-most restrictive, etc. Since you're and-ing the predicates together, an instance fails the first predicate won't need to be checked against the others. Filter out objects as early as possible in the predicate chain.</li> </ul> <p>Probably the easiest gain is by changing the order in the third predicate and then moving it to the front of the list.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload