Re: Table View Blues (summary)
Re: Table View Blues (summary)
- Subject: Re: Table View Blues (summary)
- From: Sam Griffith <email@hidden>
- Date: Fri, 22 Nov 2002 00:33:57 -0600
Let me clarify.... NSMutableStrings...... Reuse them.... I tend to not
differentiate a lot. I just think about it auto-magically...
Sam
email@hidden
On 11/21/2002 5:21 PM, "Sheehan Olver" <email@hidden> 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@hidden> 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@hidden
>
>>> Web site: http://homepage.mac.com/staypufd/index.html
>
>>>
>
>>> On 11/20/2002 3:20 PM, "Sheehan Olver" <email@hidden> 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@hidden 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@hidden
>
>>>> 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@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.