Re: Table View Blues (summary)
Re: Table View Blues (summary)
- Subject: Re: Table View Blues (summary)
- From: Sam Griffith <email@hidden>
- Date: Thu, 21 Nov 2002 01:17:04 -0600
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.