Re: Table View Blues (summary)

FROM : Sheehan Olver
DATE : Fri Nov 22 00:21:44 2002

No, I understood what you meant. The key is he wanted something that
could scale. In order to reuse NSStrings you need to keep them in
memory. Say instead of 100,000 records, there were a billion cells in
the table (remember, the solution should be something that could
scale). This means if you reuse the NSStrings you could have a billion
extra NSStrings sitting in memory. Not only that, but when the table is
closed you would have a billion NSStrings to dealloc. The fact is,
creating and destroying NSStrings is extremely fast compared to human
reaction time, meaning if you create 100 NSStrings at once, the user
won't notice. But it doesn't hold up to deallocating a billion
NSStrings at once.

On Thursday, November 21, 2002, at 01:17  AM, Sam Griffith wrote:

> 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.