Re: Table View Blues (summary)

FROM : Sam Griffith
DATE : Thu Nov 21 06:56:44 2002

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_removed>
Web site:  http://homepage.mac.com/staypufd/index.html

On 11/20/2002 3:20 PM, "Sheehan Olver" <<email_removed>> 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_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.
_______________________________________________
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.