Re: storing, searching, and displaying variable-sized data sets
Re: storing, searching, and displaying variable-sized data sets
- Subject: Re: storing, searching, and displaying variable-sized data sets
- From: Matthew <email@hidden>
- Date: Sat, 1 Jan 2005 02:42:59 -0500
Thanks to everyone who had input on this issue. Here's a relevant follow-up that involves populating a tableview with a lot of data once you have it in memory:
Once you have the data loaded into your running application (let's just assume it's an array), what might be the best way to have it loaded via bindings into a tableview for search purposes?
Trying the straight forward approach of adding each item to the NSArrayController individually with add: and calling rearrangeObjects: is taking several minutes for an array size of ~15,000 where each row is only 4 NSStrings. I'm not surprised by this really, but surely there's a way to populate it much faster and I'd like to stick to a filtered search (like Xcode's documentation for instance. Could anyone comment on how that's implemented? Does dropping the bindings and using delegates for the dataSource make that big of a difference? In Xcode, as soon as I open help, the tableview populates almost immediately and it's a pretty big table.
I'm not sure what the other obvious way would be to populate the table unless there's some very customized indexing going on. Is it not possible to do some clever variation of what I described in the preceding block of text and get a reasonably fast result for filtered searching?
If not, might the next best way be to just change
<x-tad-bigger>setSendsWholeSearchString: </x-tad-bigger>to require the user to press 'return' to trigger the search and then do a quick run through the array, adding objects to the table view as appropriate? I'd like to stick to filtered searching, but if this method turns out to be a lot less hassle, then I think I'll go with it.
HNY!
Matthew
On Dec 31, 2004, at 1:13 AM, Brendan Younger wrote:
On Dec 30, 2004, at 6:45 PM, Tim Ramsey wrote:
On Thursday, December 30, 2004, at 08:57 AM, Matthew wrote:
<snip>
If you go with 3), check into red/black trees. AFAIK algorithms based on red/black tree methods are presently the fastest way to access huge data volumes.
(If they are not, someone give a faster one. I'm interested too.)
Algorithmically, sure, red-black trees are pretty close to fastest. However, if you want to make the simplifying assumption that all your data will reside in "memory" (relying on the VM system heavily), then you're probably better with skip lists. I know it sounds silly that a linked-list variant would beat any sort of sophisticated tree approach, but when you factor in locality of reference, and the general data access pattern for searching, you wind up trashing your caches (both on-chip and in the VM system) with trees and therefore do much, much better with skip lists. Besides, they're a lot easier to program anyway.
Brendan Younger
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden