I've been trying to solve a mystery the past few days as to why my NSFetchedResultsController with a batch size of 20 would always fault in (that is, load into memory) all my objects immediately when the fetch was finished, causing the request to take ~ 20 seconds.
It turns out that it was because in my heightForRowAtIndexPath, the height was based on the length of an NSString property of each fetched object, and so upon reloading the table, if the table has 2000 rows, then the height is calculated for every row in the beginning, and since I access a text property of the object, it would fault in 2000 objects (in 20 size batches) right in the very beginning, causing it to take forever. (I didn't know row heights were calculated all in the beginning).
So the question is, if I have a fetch results controller with a batch size of 20, but my row heights are based on a text property of the object, which if I try to access would cause the object to not be a fault anymore but actually loaded into memory, what would be a workaround to calculating the height?
What are my options?
Interesting question. What I would do to boost performance would be to create a property in your model that store the length for that string text. In this way you don't need to calculate the length for each row on the fly but you have a pre-calculated height.
Myabe there could be other valuable solutions.
Create a static method in your view controller class that is in charge of calculating the said height. All you need to supply this function is an NSString and it should return an easily calculated CGFloat. Use this method for returning the needed height of your elements without instantiating them (all you need here is the meta-data of their text).
来源：https://stackoverflow.com/questions/11170762/dynamic-uitableview-height-with-core-data-objects