Using variable heights with NSFetchedResultsController?

Question

What's the best way to design/use my model and NSFetchedResultsController so that I can use a table with variable height cells? Computing the height is expensive (and requires access to the model's data) so I'm caching the value in my model. However, I know that the tableview will ask for heights of all visible cells.

My current thought is that I will limit the number of results, and allow the user to fetch larger numbers themselves to prevent too much load.

My concerns, however, are that my rows contain about 200 bytes each of relevant data. It's true that faulting 200 rows will only take up about 20k, but what if I wish to display 20000? I'll fault 2MB of raw data just to set cell heights.

There's one attribute that takes up about 90% of the data. That means I could keep the main entity down to 20 bytes per row. Is it worth it to save it in a seperate entity so that I can avoid faulting it in if not needed?

One final note: cell height is entirely dynamic and depends on the content. If there were only a couple of possible choices, this would be much simpler.

Answer 1

If you can enumerate cell types, based on the content you pour into a cell, and store the cell type in your data model, you could do a switch-case tree to return standard, pre-calculated heights on a per-cell basis.

Answer 2

Thankfully, as of iPhone SDK 3.1, we can trace the sql calls used by Core Data. It turns out that for small amounts of data (like 200 bytes per cell), performance is much much better if you keep it all in the same entity. For the example above (with 20000) cells, Core Data may very well perform 2000 additional requests to get the data it needs, and the fetch request overhead becomes troublesome. At that stage, it's better to use batching to speed things up.