NSArray 过滤：在哪种情况下使用谓词，在哪种情况下使用块？
性能方面，在一个相对较大的数组上（到目前为止，原始数组的通常计数是±20000），哪种方法最适合过滤它？块还是谓词？
所包含对象的大多数 ivar 都是字符串，我想查询它们。
Performance wise, on a relatively large array (so far the usual count for the original array is ±20000), which method is best suited to filter it? Blocks or predicates?
Most of the ivars of the contained objects are strings and I want to query those.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
有一种方法可以使块更快：
NSEnumerationConcurrent枚举数组。但是，文档没有明确说明并发枚举时将保留顺序。我认为这是一个很好的选择，但事实并非如此。如果数组的顺序很重要，则必须重新排序（如果可能的话），并且必须将其包含在任何计时比较中。
其他方法是使用块非并发枚举和使用谓词进行过滤。
filterUsingPredicate:可能会更快，因为 NSArray 将有机会使用内部知识来比重复的addObject:消息更快地构建结果数组。但这只是一种可能性；唯一确定的方法是比较，即使这样，答案也可能随时改变（包括在同一进程中，对于不同的输入数组或数组中的不同对象）。我的建议是首先使用谓词直接实现它，然后使用 Instruments 来查看是否存在性能问题。如果不是，清晰的代码会获胜。如果是性能问题，请尝试并发枚举。
There is one way that blocks could be faster:
NSEnumerationConcurrentto enumerate the array.However, the documentation doesn't explicitly say that order will be preserved when enumerating concurrently. I think it's a good bet that it won't be. If the order of the array matters, you'd have to re-sort (if that's even possible), and you'd have to include that in any timing comparison.
The other ways are to non-concurrently enumerate using blocks and to filter using predicates.
filterUsingPredicate:could be faster, since NSArray will have the opportunity to use internal knowledge to build the result array faster than repeatedaddObject:messages. But that's merely a possibility; the only way to know for sure would be to compare, and even then, the answer could change at any time (including in the same process, for different input arrays or different objects in the array).My advice would be to implement it straightforwardly—using predicates—at first, and then use Instruments to see whether it's a performance problem. If not, clear code wins. If it is a performance problem, try concurrent enumeration.
当谈论性能时，很难击败实验。我们可以就块或使用的任何解决方案的各种性能影响争论一整天，但最好是测量应用程序中使用的实际数据。
When talking about performance it’s hard to beat an experiment. We could argue a whole day about the various performance implications of blocks or whatever solution used, but it’s best when you measure on the actual data used in your application.