Re: Table View Blues (summary)

FROM : Sheehan Olver
DATE : Wed Nov 20 22:20:11 2002

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_removed> 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_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.