Re: Table View Blues (summary)

FROM : Sam Griffith
DATE : Thu Nov 21 08:17:04 2002

I think you mis-understood my addition.  I am saying don't dealloc the
NSStrings!  Not the char * strings.  It is cheaper to dealloc the char *
strings than the NSStrings.  Reuse the NSStrings....

Sam

On 11/21/2002 12:31 AM, "Sheehan Olver" <<email_removed>> wrote:

> Well, except his big issue was the deallocation when the window is
> closed. Suppose a user clicks the down arrow through _all_ the, say,
> 100,000 records. Under your method 100,000 strings would be in memory.
> Under my method, at any given time there would be a window full of
> strings (say 30 per column) with an overhead for the constant creation
> and deletion. But when the window closes your method would require
> 100,000 deallocs, where mine would only require 30 deallocs for the
> currently displayed records.
>
> On Wednesday, November 20, 2002, at 11:56  PM, Sam Griffith wrote:
>
>> 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.