setFetchBatchSize似乎无法正常工作 [英] setFetchBatchSize doesn't seem to work properly

问题描述

我就这个主题提出几个问题，但仍然无法使其发挥作用。我有一个核心数据，我在桌面视图中显示了10k +行的人名。我希望能够用每个字母搜索和更新表格。这是非常迟钝的。正如我所建议的那样，我观看了WWWDC '10核心数据演示，并试图实现

I ask a few questions on this topic but still can't get it to work. I have a core data with 10k+ rows of people names that i am showing in a tableview. I would like to be able to search and update the table with every letter. It's very laggy. As suggested i watch the WWWDC '10 core data presentation and was trying to implement

[request setFetchBatchSize:50];

似乎不起作用。当我使用仪器检查核心数据时，它仍然显示在加载tableview时仍有10k请求，当我搜索它时也获得所有结果。
是否还需要做任何其他事情来设置批量大小，或者那些不会对我有帮助。

Doesn't seem to work. When i use instruments to check core data it still shows that there is still 10k request when loading the tableview and when i search it also gets all the results. Is there anything else that needs to be done to set the batch size or thats not something that will help me.

唯一可行的方法是我搜索时将fetchlimit设置为100。您认为这是一个很好的解决方案吗？

The only thing that seems to work is setting the fetchlimit to 100 when i search. Do you think its a good solution?

提前致谢！

推荐答案

批量大小只是告诉它一次要获取多少个对象。这可能不会对你有所帮助。让我们稍微考虑你的用例...

The batch size just tells it how many objects to fetch at a time. This is probably not going to help you very much. Let's consider your use case a bit...

用户键入F并告诉数据库Go找到所有以'F'开头的名字并且数据库查看所有10k +记录以查找以'F'开头的记录

The user types "F" and you tell the database, "Go find all the names that start with 'F'" and the database looks at all 10k+ records to find the ones that start with 'F'

然后，用户输入'r'，因此您告诉数据库去查找所有以Fr开头的记录，它再次查看所有10k +记录，找到以Fr开头的记录。

Then, the user types 'r', so you tell the database to go find all the records that start with "Fr" and it again looks at all 10k+ records to find the ones that start with "Fr."

所有fetchBatchSize正在做的就是告诉它嘿，当你在记录中出错时，立即加入50，因为我可能还需要所有这些。这没有什么限制你的搜索。

All fetchBatchSize is doing is telling it "Hey, when you fault in a record, bring in 50 at once because I'm going to probably need all those anyway." That does nothing to limit your search.

然而，将fetchLimit设置为100有助于一些因为数据库开始搜索所有10k +记录，但一旦它有100条记录，它不必继续查看其余的记录，因为它已经填满了它的请求。它已经完成，并且一旦获得满足请求的100条记录就停止搜索。

However, setting fetchLimit to 100 helps some because the database starts hunting through all 10k+ records, but once it has its 100 records, it does not have to keep looking at the rest of the records because it already has filled its request. It's done, and stops searching as soon as it gets 100 records that satisfy the request.

所以，你可以做几件事，这些都取决于你的其他用例。

So, there are several things you can do, all depending on your other use cases.

最简单的尝试是在您要搜索的字段上添加索引。您可以在Xcode模型编辑器中设置它（指向Indexes的部分，在您可以在检查器中命名实体的位置）。这将允许数据库在该字段上设置特殊索引，并且搜索速度会快得多。

The easiest thing to try is adding an index on the field that you are searching. You can set that in the Xcode model editor (section that says Indexes, right under where you can name the entity in the inspector). This will allow the database to setup a special index on that field, and searching will be much faster.

其次，在初始请求之后，您已经有了一个名称数组以'F'开头，所以没有必要回到数据库来询问以'Fr'开头的名字如果它以'Fr'开头，它也以'F'开头，你已经有了所有的NSManagedObject指针那些。现在，你可以只搜索你得到的数组。

Second, after your initial request, you already have an array of names that begin with 'F' so there is no need to go back to the database to ask for names that begin with 'Fr' If it begins with 'Fr' it also begins with 'F' and you already have NSManagedObject pointers for all of those. Now, you can just search the array you got back.

更好的是，如果给它一个排序描述符，数组就会被排序。因此，您可以对阵列执行简单的二进制搜索。或者，如果您愿意，可以使用相同的谓词，并将其应用于结果数组而不是数据库。

Even better, if you gave it a sort descriptor, the array is sorted. Thus, you can do a simple binary search on the array. Or, if you prefer, you can just use the same predicate, and apply it to the results array instead of the database.

即使您不使用结果 - 我刚刚讨论过修剪，我认为对该属性进行索引将会大幅提升。

Even if you don't use the results-pruning I just discussed, I think indexing the attribute will belt dramatically.

编辑

也许你应该运行乐器，看看你花多少时间在哪里。而且，一个形式错误的谓词可以使任何指数方案屈服。代码会有所帮助。

Maybe you should run instruments to see how much time you are spending where. Also, a badly formed predicate can bring any index scheme to it knees. Code would help.

最后，考虑一下你带入内存的元素数量。 CoreData不会对所有信息进行错误处理，但它会为数组中的所有内容创建shell。

Finally, consider how many elements you are bringing into memory. CoreData does not fault all the information in, but it does create shells for everything in the array.

如果给它一个排序谓词，

If you give it a sort predicate,

我不知道SQLLite如何在索引上实现其搜索，但是B-Tree具有复杂性logBN，所以即使在30k记录上，这也不是很多搜索。除非你有另一个问题，索引应该给你一个很大的改进。

I don't know how SQLLite implements its search on an index, but a B-Tree has complexity logBN so even on 30k records, that's not a lot of searching. Unless you have another problem, the indexing should have given you a pretty big improvement.

一旦你有索引，你就不应该检查所有记录。但是，您仍可能拥有非常大的数据集。在那些上尝试fetchBatchSize，因为它将限制获取的记录数，并为其余的创建代理。

Once you have the index, you should not be examining all records. However, you still may have a very large set of data. Try fetchBatchSize on those, because it will limit the number of records fetched, and create proxies for the rest.

你也可以调用countFetchRequext而不是executeFetchRequest来获取数量项目。然后，您可以使用fetchLimit来限制您获得的数字。

You can also call countFetchRequext instead of executeFetchRequest to get the number of items. Then, you can use fetchLimit to restrict the number you get.

至于使用获取的结果控制器完成所有这些...好吧，那家伙必须知道记录，所以它仍然需要进行搜索。

As far as working all this with a fetched results controller... well, that guy has to know the records, so it still has to do the search.

此外，还有一个地方要看......你在做什么部分？如果您有任何用户定义的比较器（比如翻译部分），那么每个记录都会调用它。

Also, one place to look... are you doing sections? If you have a user defined comparator for anything (like translating for sections) this will get called for every single record.

因此，我猜我的重要建议是指数变化，就是运行工具并真正研究它以确定你在哪里花时间。应该很明显。这将有助于引导您走向真正的问题。

Thus, I guess my big suggestion, after making the index change, is to run instruments and really study it to determine where you are spending your time. It should be pretty obvious. That will help steer you toward the real issue.

我敢打赌，您仍然可以出于某种原因访问所有元素......

My bet is that you are still access all of the elements for some reason...

这篇关于setFetchBatchSize似乎无法正常工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！