On Jul 3, 2009, at 4:39 PM, mmalc Crawford wrote:

On Jul 3, 2009, at 11:54 AM, Brian Slick wrote:

I did make a slight adjustment to the technique - most significantly the omitting of the identifier in the XIB file,

This is actually a very significant factor.
If you haven't set an identifier, it's not clear how you're retrieving cached cells in tableView:cellForRowAtIndexPath:?

I assume you have a test along the lines of:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
   if (cell == nil) {
       cell = ...

Could you check whether you're creating a new cell each time?

That's impressive; good call. It was indeed creating a new cell each time. And now that I take a second look at the code, I'm pretty sure I see why. The XIB-loading command itself doesn't actually have the identifier as a parameter, and is thus totally dependent on that info being in the XIB. Therefore, the cell never gets queued. My initial thought was that omitting it would make it generic, but I now see the flaw in that thinking. Simply declaring the identifier doesn't make it get used anywhere. :p

Incidentally, that's what is wrong with TaggedLocations... it also does not have the identifier in the XIB. I manually added it, then retested, and saw dramatically better performance (for my own program, too).

So now I either need to figure out how to make my scenarios all work with a single identifier, or I may just go ahead with the code-only cell I just built in response to the performance issue. If would be nice if there was some kind of queueWithReuseIdentifier: method for these XIB cases. (This is what I'm trying to do: http://bit.ly/l55eH )

All this aside, please file a performance bug against the TaggedLocations sample.

Done, although I'm not sure if I did so correctly. Thank you for your help.

Brian

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to