Trygve Inda wrote:
Each dictionary (or object with properties) will need to hold
roughly 9
textual strings, and there will be on the order of 10,000 objects
in the
array. I am guessing that dictionary will perform better than a
predicate
filter given the number of objects.
Never guess at performance. Always measure. For one thing, "perform
better" may be irrelevant. "Good enough" is the only criterion worth
evaluating. If worse performance is good enough, then better
performance serves no purpose (ignoring other tradeoffs, such as
power consumption). If array search is 10 msecs, and dictionary
search is 10 usecs, the user will never perceive the thousand-fold
difference if the search occurs at most 10 times per sec.
In addition, if the objects are ordered in the array, a binary search
instead of linear is simpler than managing a parallel dictionary for
keyed retrieval. Binary search is O(log2(n)) worst-case.
http://en.wikipedia.org/wiki/Binary_search_algorithm
It almost seems like you're choosing representations and algorithms
primarily on the existence of classes, instead of what might work
best. That is, because predicate filter classes exist, you don't
have to write that class, so you've decided to use it for searching
arrays instead of other algorithms that may have substantially better
performance, but for which you'd have to write non-trivial code (or
find it on the web). And the only tradeoffs you're making are
between varieties of existing Apple-supplied classes, e.g.
NSDictionary vs. NSArray with predicate-search, rather than looking
for third-party classes.
-- GG
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
