Re: Table View Blues (summary)

FROM : Sam Griffith
DATE : Fri Nov 22 07:33:57 2002

Let me clarify.... NSMutableStrings...... Reuse them.... I tend to not
differentiate a lot.  I just think about it auto-magically...


Sam
<email_removed>


On 11/21/2002 5:21 PM, "Sheehan Olver" <<email_removed>> wrote:

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