Back in the day of the iPhone 3G, iPhone 3GS and to a lesser extent the iPad 1, what adamjernst described below was how you got the best performance http://news.ycombinator.com/item?id=3692126
I would argue that nowadays with the power in the iPhone 4, iPhone 4S, iPad 2 and the new iPad (aka iPad 3) this is a premature optimization. The raw computing power of these devices makes creating a UITableViewCell with basic subviews total useable without affecting scrolling performance. I've worked on almost a dozen iOS apps in the last two years and that is all I do anymore.
Now about diagnosing the problem. 99% of the time the cause of the problem is one of two things:
1) Not reusing UITableViewCells
2) Doing way too much work on the UI thread
UITableView has a method called dequeueReusableCellWithIdentifier: which allows you to get access to a cell in a table view that is no longer being used. This allows you to reuse the cell instead of releasing the memory of that cell and creating a new one.
Memory allocation is expensive and if you had a table with 100 rows you could end up allocating memory for 100 UITableViewCells. Now on the iPhone if you are reusing cells you'd probably only allocate the memory 7-10 times (depending on the height of your rows) and then change little pieces inside it (like the text of the cell or the image that it is displaying). An easy way to see this is to create a demo app that has 1000 rows which are populated with random text, images you include in the bundle. Don't reuse table view cells and scroll up and down as fast as you can. You'll notice the scrolling is choppy. The second you reuse the the table view cells it will "magically" improve.
The second cause is people doing too much work on the UI thread. This is just bad practice and with the advent of Grand Central Dispatch and NSOperation you can simply take a block of code that is eating up a lot of time on the UI thread and pass it into the constructor of a NSBlockOperation and do all the work in the background. Some common examples of this are pulling data from a web service, converting data from a web service into local entities, reading from a local database (i.e. sqlite), sorting collections, etc.
If after solving these two problems your app is still jerky then it is perhaps time to look at adamjernst solution. But in my time I've created some pretty complex UITableViewCells in tables that have hundreds of entries and my scrolling is always butter smooth.
I would argue that nowadays with the power in the iPhone 4, iPhone 4S, iPad 2 and the new iPad (aka iPad 3) this is a premature optimization. The raw computing power of these devices makes creating a UITableViewCell with basic subviews total useable without affecting scrolling performance. I've worked on almost a dozen iOS apps in the last two years and that is all I do anymore.
Now about diagnosing the problem. 99% of the time the cause of the problem is one of two things:
1) Not reusing UITableViewCells 2) Doing way too much work on the UI thread
UITableView has a method called dequeueReusableCellWithIdentifier: which allows you to get access to a cell in a table view that is no longer being used. This allows you to reuse the cell instead of releasing the memory of that cell and creating a new one.
Memory allocation is expensive and if you had a table with 100 rows you could end up allocating memory for 100 UITableViewCells. Now on the iPhone if you are reusing cells you'd probably only allocate the memory 7-10 times (depending on the height of your rows) and then change little pieces inside it (like the text of the cell or the image that it is displaying). An easy way to see this is to create a demo app that has 1000 rows which are populated with random text, images you include in the bundle. Don't reuse table view cells and scroll up and down as fast as you can. You'll notice the scrolling is choppy. The second you reuse the the table view cells it will "magically" improve.
The second cause is people doing too much work on the UI thread. This is just bad practice and with the advent of Grand Central Dispatch and NSOperation you can simply take a block of code that is eating up a lot of time on the UI thread and pass it into the constructor of a NSBlockOperation and do all the work in the background. Some common examples of this are pulling data from a web service, converting data from a web service into local entities, reading from a local database (i.e. sqlite), sorting collections, etc.
If after solving these two problems your app is still jerky then it is perhaps time to look at adamjernst solution. But in my time I've created some pretty complex UITableViewCells in tables that have hundreds of entries and my scrolling is always butter smooth.