ios - 谓词中的逻辑运算符是否与 NSFetchRequest 短路？
<p><p>我有一个使用逻辑 OR 运算符的 <code>NSPredicate</code>，如下所示:</p>
<pre><code>NSPredicate(format: "activeFrom == NULL OR %@ >= activeFrom", someDate)
</code></pre>
<p>当我使用此谓词从 CoreData 获取结果时，使用 <code>NSFetchRequest</code>，评估是否短路，因此如果第一个子句评估为 true，则不会评估第二个子句？</p >
<p>对于 Apple 来说，这似乎是一个明智的优化，但我在文档中找不到任何官方信息来确认它。</p></p>
<br><hr><h1><strong>Best Answer-推荐答案</ strong></h1><br>
<p><p>来自 <a href="https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/Performance.html#//apple_ref/doc/uid/TP40001075-CH25-SW1" rel="noreferrer noopener nofollow">Core Data Programming Guide</a> ，性能部分:</p>
<blockquote>
<p><strong>Fetch Predicates</strong></p>
<p>How you use predicates can significantly affect the performance of your application. If a fetch request requires a compound predicate, you can make the fetch more efficient by ensuring that the most restrictive predicate is the first, especially if the predicate involves text matching (contains, endsWith, like, and matches). Correct Unicode searching is slow. If the predicate combines textual and nontextual comparisons, it is likely to be more efficient to specify the nontextual predicates first; for example, (salary > 5000000) AND (lastName LIKE 'Quincey') is better than (lastName LIKE 'Quincey') AND (salary > 5000000). For more about creating predicates, see Predicate Programming Guide.</p>
</blockquote>
<p>所以，是的，谓词的评估似乎已如您所料优化。这在很大程度上取决于 SQLite 如何优化相应的 WHERE 子句(假设您使用的是 SQLite 存储)。</p></p>
<p style="font-size: 20px;">关于ios - 谓词中的逻辑运算符是否与 NSFetchRequest 短路？，我们在Stack Overflow上找到一个类似的问题：
<a href="https://stackoverflow.com/questions/48148709/" rel="noreferrer noopener nofollow" style="color: red;">
https://stackoverflow.com/questions/48148709/
</a>
</p>
页:
[1]