Re: Table View Blues (summary)
Re: Table View Blues (summary)
- Subject: Re: Table View Blues (summary)
- From: Sam Griffith <email@hidden>
- Date: Wed, 20 Nov 2002 23:56:44 -0600
Let me add to this, because this is a good way to handle it if you are
worried about memory... Don't let the NSStrings get dealloc'ed. Reuse them.
This is cheaper and probably faster.
--
Sam Griffith Jr.
email: email@hidden
Web site:
http://homepage.mac.com/staypufd/index.html
On 11/20/2002 3:20 PM, "Sheehan Olver" <email@hidden> wrote:
>
I thought of a solution around the release/retain problem you seemed to
>
have. Now suppose you manage to get your data in a c string array. You
>
can use this as your backend as opposed to an NSMutableArray:
>
>
char[][] *data; // string for row, column: data[column][row]
>
int numRows;
>
>
NSString *column1Name, *column2Name,
>
>
- (int)numberOfRowsInTableView:(NSTableView *)aTableView
>
{
>
return numRows;
>
}
>
>
- (id)tableView:(NSTableView *)aTableView
>
objectValueForTableColumn:(NSTableColumn *)aTableColumn
>
row:(int)rowIndex
>
{
>
if([[aTableColumn identifier] isEqual:column1Name])
>
return [NSString stringWithCString:data[column][row]];
>
else if ...
>
}
>
>
Now, assuming the table only calls the get the second method when a row
>
is displayed, it will constantly be creating and releasing NSStrings,
>
but only say 25 or however many are displayed at a time. This means
>
that sum total of deallocating is the amount of time it takes to free
>
the data array, since no objects are used for your backend. I hope this
>
is what you were looking for.
>
>
>
On Wednesday, November 20, 2002, at 12:00 AM,
>
email@hidden wrote:
>
>
> I couldn't have put it better myself, Alex - and I didn't! Thanks.
>
>
>
> And yes, this is the crux of the matter. When dealing with large
>
> quantities of data - let's not say "thousands of records", let's just
>
> say "something that is scalable", you can never get away from the onus
>
> of loading the data. That much we know. But we also know that in
>
> practice you are going to run into trouble when doing away with that
>
> data, and for two reasons:
>
>
>
> 1.) Your visual interface has to be able to dispense with the whole
>
> ball of wax in a single call.
>
>
>
> 2.) Your internal representation has to be able to do the same.
>
>
>
> A file of several hundred KB should load and reload instantaneously.
>
> Now if the table view can just shrug its shoulders and say "he says
>
> there are no rows, OK, so there's no rows" - if it's that simple, then
>
> we're over one hurdle.
>
>
>
> But underneath - in the data management - something more streamlined
>
> has to be engineered. Just guessing, but is there a way to work all
>
> this into an autorelease pool? For that would solve it all - given
>
> that the pool doesn't waste valuable real time...
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.