Re: Table View Blues
Re: Table View Blues
- Subject: Re: Table View Blues
- From: <email@hidden>
- Date: Mon, 18 Nov 2002 12:43:23 +0000
- Organization: Rixstep
--- j o a r <email@hidden> wrote: > How often would you replace the contents of the table view? If you
>
>
switch the contents of the table view so often that memory
>
allocation / deallocation is a serious bottleneck, don't you
>
think that this would cause the table view in itself to be
>
almost useless as an UI element?
Absolutely not. I have several examples where it not only is necessary, but works fine - given the memory stuff I can use where I have recently been.
>
What would happen when the user is scrolling through the table
>
view, looking for something or keeping a selection, et.c., and you
>
switch the data?
I don't switch data - the user does. The user cannot switch data and scroll at the same time. I agree that this seems unfeasible with the NSTableView, but it shouldn't be - and it isn't, on other platforms.
>
I'm not sure that I agree with using just one table view for
>
displaying 20.000 records
20,000 is an example. Most real life situations will require a lot more.
>
it would be rather difficult to navigate
Not as things stand at the present - on the other platform. There is nothing difficult about it at all.
>
Have you benchmarked this? Where's the bottleneck?
Don't need to. There is too much happening. Correction: there is _something_ happening, whereas where I have been there is nothing. Two calls and that's it: vacate the view, and good-bye to all data. Two (2) calls.
The bottleneck is naturally in the recursive deallocs, for each string for each column for each row in the view.
>
Here's a short snippet to read a comma separated file to be used
>
for a table view:
>
>
- (void) loadTableDataFromFile:(NSString *) path
>
{
>
NSString *str = [NSString stringWithContentsOfFile: path];
>
NSArray *arr = [str componentsSeparatedByString: @","];
>
>
[myTableViewArray setArray: arr];
>
[myTableView reloadData];
>
}
>
>
No error checking, no sorting, et.c., but you get the idea...
Yes, this is very cool, but it's not on the upside that the problem occurs. We all know we have to get the data in there. What we cannot afford is a haphazard memory arrangement so we're spending as much time getting rid of it later.
>
I would suggest reading and parsing files in a separate thread if
>
the responsiveness of the GUI is important.
For what today is at most a one second delay, I hardly think this is justified.
>
That said, NSTableView is provided as a general purpose control -
>
not suited for very large tables with a high frequency of updates.
OK, fine, sure. Then what control does NS have for large tables?
>
the main limitation is that you can only choose to update the
>
whole table view, and not just a given x,y cooordinate in the
>
table through the public API of NSTableView
I'm prepared to accept this. In both models, the drawing of the view is left to the view itself, and the application responds to needs for data to be displayed. That's the view's problem, but I've never seen a view hiccup for that...
>
In our main application we've created our own table view optimized
>
for our particular needs and this might be something that you need
>
to do if NSTableView cannot keep up properly.
Yeah, I'm getting that picture. My complaint isn't so much with the view itself, but with the lack of tidy memory management underneath. That's where the clocks are saved.
The picture I am getting is that Apple/NS are unsurpassed at graphics, but that types of business things are a bit unfamiliar for them. I would hate to give MS the win on this one, but it looks like their crummy listview, coupled with Cutler's memory management, wins this round.
Unfortunately. ://
Cheers, R.
_______________________________________________
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.