Re: Table View Blues (summary)

FROM : Sheehan Olver
DATE : Thu Nov 21 07:31:10 2002

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.