Re: Table View Blues (summary)
Re: Table View Blues (summary)
- Subject: Re: Table View Blues (summary)
- From: Sheehan Olver <email@hidden>
- Date: Thu, 21 Nov 2002 00:31:10 -0600
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.