I have a UITableView with about 400 cells in 200 sections and it\'s a little sluggish in responding to user interaction (scrolling, selecting cells.) I\'ve made sure the met
The best thing you can do if you're looking to speed up your code is to profile it. There are two reasons for this:
You can read about some things that'll improve table performance in general, like using fixed-height cells and re-using cells, and it'll probably help to implement those things (looks like you've already done that). But when it comes to speeding up your code, you really need to know where you app is spending most of its time. It might be that there are a few methods that take a very long time, or a method that's relatively quick but gets called a lot more often than you'd expect.
It's impossible to know whether the changes you make in an effort to speed things up truly make a difference unless you have some numbers to measure against. If you can show that your code was spending 80% of its time in one routine and you cut that down to 35%, you know you're making progress.
So, break out Instruments and start measuring. If you can, it's a good idea to measure while you're doing each of the different activities that you want to speed up... do one profiling session while scrolling, one while selecting as many different cells as you can in a fixed period, etc. Don't forget to save the results so you can compare later.
Just note these points..
Some good info about cell reuse is here..
EDIT : Found this page very late..
This SO question thread might help you...especially the accepted answer...
Even if your cell is actually that simple (background image and label) there are some things to consider
Image caching This is the obvious thing - if you are using the same image everywhere, load it once into the UIImage and reuse it. Even if the system will cache it on its own, directly using the already loaded one should never hurt.
Fast calculation Another rather obvious thing - make calculating height and content as fast as possible. Don't do synchronous fetches (network calls, disk reads etc.).
Alpha channel in image What's expensive when drawing is transparency. As your cell background has nothing behind it, make sure that you save your image without alpha channel. This saves a lot of processing.
Transparent label The same holds true for the label on top of your background view, unfortunately making it opaque might ruin the looks of your cell - but it depends on the image.
Custom cell
In general, subclassing UITableViewCell
and implementing drawRect:
yourself is faster than building the subview hierarchy. You might make your image a class variable that all instances use. In drawRect:
you'd draw the image and the text on top of it.
Check compositing The simulator has a tool to highlight the parts that are render-expensive because of transparency (green is ok, red is alpha-blending). It can be found in the debug menu: "Color Blended Layers"
Are you using a lot of subviews?
If so, a good technique is to, instead of adding a lot of labels and images, draw them using CoreGraphics.
To do this, you'd have to subclass UITableViewCell and implement the -(void)drawRect:(CGRect)rect
method.
Reuse cells. Object allocation has a performance cost, especially if the allocation has to happen repeatedly over a short period—say, when the user scrolls a table view. If you reuse cells instead of allocating new ones, you greatly enhance table-view performance. Avoid relayout of content. When reusing cells with custom subviews, refrain from laying out those subviews each time the table view requests a cell. Lay out the subviews once, when the cell is created. Use opaque subviews. When customizing table view cells, make the subviews of the cell opaque, not transparent.
Does the table view's delegate implement:
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
If so you may wish to consider setting your UITableViewCell's rowHeight property instead.