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 17:21:44 -0600
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.