Re: Table View Blues
Re: Table View Blues
- Subject: Re: Table View Blues
- From: Alex Rice <email@hidden>
- Date: Mon, 18 Nov 2002 00:54:06 -0700
On Sunday, November 17, 2002, at 10:28 PM, Rixstep wrote:
The table view (NSTableView) is, in my humble opinion, one of the
most important of all GUI controls. When you start interfacing with
databases, its use becomes vital. But there seems to be a lack of
flexibility with regard to the Cocoa NSTableView. Let me explain by
first explaining what I am used to, and then by explaining what I
perceive as the issues with the Cocoa implementation.
I have no actual experience programming with very large # of rows in
NSTableView or on Windows, but it's an interesting question so what the
heck...
I think your question could be recast as "How do I implement a very
fast NSTableDataSource in Objective-C without the bottleneck of
alloc-ing and dealloc-ing thousands or millions of records and stuffing
them into a NSMutableArray?"
Here are some other thoughts:
NSTableView will be perfectly happy, and quick, (I think I haven't
tried it) if at one moment, the data source says -
numberOfRowsInTableView: = 100,000, and then you do
/* suppose loadAnotherRecord deallocs 100K records and loads another
500K */
[dataSourceObj loadAnotherRecord];
[tableViewOutlet reloadData];
The bottleneck in the above two lines is going to be how fast your
dataSourceObj can do the unload & reload, not how fast the
tableViewOutlet reload. In the worst case the NSTableView is releasing
(just a retain count, not dealloc-ing anything) all the objects it has
gotten from tableView:objectValueForTableColumn:row: and then
NSTableView is redrawing itself. So the bottleneck would still be with
the data source, not the NSOutlineView.
The NSTableDataSource protocol cleanly separates the data and the
tableview using the MVC pattern (model, view, controller). Maybe that's
what you meant by "MO"; model object?
NSTableDataSource doesn't say anything about how the data source should
be implemented, just that the data source object implementing
NSTableDataSource must respond to those messages. So your data source
object need not internally use a NSMutableArray for records. It could
even lazily read records as needed off disk using whatever portable
file format you are using. It could use C arrays, C++ STL containers,
or a database library, instead of ObjC containers for implementing the
structure of the records and record access.
However, I do think that using ObjC container classes like
NSMutableArray would be the best way to implement the data source for
most developers initially unless one find performance to be
unacceptable with all those objects getting alloc-ed and dealloc-ed
when files are opened and closed. So it seems you have enough records
to hit that bottleneck.
Also maybe consider using -noteNumberOfRowsChanged on NSTableView as it
allows you to display data to the user while more records are being
loaded. Might be useful if you are constructing objects to stuff into a
Alex Rice <email@hidden>
Mindlube Software
http://mindlube.com/
_______________________________________________
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.