Re: Display csv in a tableView with bindings
Re: Display csv in a tableView with bindings
- Subject: Re: Display csv in a tableView with bindings
- From: "I. Savant" <email@hidden>
- Date: Sun, 26 Jul 2009 17:38:47 -0400
On Jul 26, 2009, at 3:52 PM, Aaron Burghardt wrote:
Not necessarily. If the keys are NSStrings, then they are copied
when added to the dictionary, but a copy of an immutable string is
optimized to just retain it, so the data isn't duplicated (assuming
all rows have the same columns in the same order, an assumption you
don't seem to be making).
Actually, I temporarily take back my "you're probably right"
response. :-) I can't find a reference to this anywhere, but I
admittedly only looked in the NSString API reference, the Introduction
to Strings Programming Guide for Core Foundation and quickly perused
the The Objective-C 2.0 Programming Language.
Would you mind directing me to where this is stated? I'm not saying
you're wrong - it sounds plausible - I'm just not sure you're right. :-)
Keep in mind that an NSArrayController created in Interface Builder
is defined by default to create an NSMutableDictionary for each item
in the dictionary.
I missed this the first time around, sorry.
With respect, I don't see how this is relevant to my point. It only
illustrates that NSMutableDictionary is an acceptable container (and
it's the default for NSArrayController because it's *the* generic
Cocoa container that fits in nicely with KVC). That it's the default
says nothing about its performance when there are hundreds of
thousands of them to create and manipulate.
It's not unreasonable, and we don't know the OP's performance
requirements.
No, it's not unreasonable, but since we don't know the OP's
performance requirements, the original blanket statement that
NSDictionary is better won't do without these caveats (ie, "it's
easier for bindings, but dog-slow on reasonably large files"). Rather
than just say "there's more to it than that" as a drive-by correction,
I wanted to provide a helpful explanation and workaround, since this
is an area in which I have recent and detailed experience. :-)
--
I.S.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden