iOS UITableview - improving performance with AutomaticDimension

A significant improvement was made to UITableview and the process of calculated cell heights with autolayout, in iOS8. With the introduction of using AutomaticDimension for row height, you can now use proper autolayout for each cell, and you can have all sorts of dynamic stuff happening to the height of a cell, and the UITableView responds as you would hope.

There are various things to do to make this work, but this post is not about that, and you will find plenty of others that cover that well.

This is about the performance of your tableview, while using this technique.  Because I was finding my performance was not great - and I didn't know why.

The great advantage of a UITableView of course, is that only what you see on the screen is being created and managed by the view.  It looks like you have a big long table full of stuff, but you don't - its all being moved around with magical smoke and mirrors.

Now you would expect that only enough cells are being created at any one time - but you would be wrong.  What is happening when using this particular technique, is that the value you set for estimatedRowHeight is used to calculate how many cells are required (because the UITableView cannot know, until after drawing has taken place, how high a cell actually is, and therefore, how many cells are needed to fill the visible part of the table).

So imagine your tableview is 400 px high.  You have set estimatedRowHeight to 40.0.  This means that the UITableView will go and prepare (400 / 40 =) 10 cells to be shown on the screen.  Even if actually, after autolayout, it turned out we only needed 5 cells - still, it went and made those cells.

SO its this estimatedRowHeight value that can play a key part in the speed of your tableview.  If you set it to a high value, eg in this case, 100 px, then only 4 cells are built for the view.  If later the tableview realises that more cells are required, then more can be built as required.

But ultimately, it pays to be as accurate as you possibly can with this value for estimatedRowHeight.  In my case, my estimate was too low, and I was building way more cells that I ever needed.  So I was wasting valuable processor time, on the main thread of course, and the app was slowing down.