Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: storing, searching, and displaying variable-sized data sets

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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: storing, searching, and displaying variable-sized data sets (From: Tim Ramsey <email@hidden>)
 >Re: storing, searching, and displaying variable-sized data sets (From: Brendan Younger <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.