On Jul 7, 2009, at 05:24, Rick Hoge wrote:
I have a nib file in which entries in an NSTableView are bound to an
NSMutableArray via an NSArrayController. It is used in an
application running under garbage collection.
The array items are NSDictionaries, and one of these dictionaries
contains a large dataset object that consumes a lot of memory. I
noticed that, while I scrolled in the tableview, many copies of
these large objects were being created and then immediately collected.
This might have something to do with the way that proxy objects are
used by the array controller, or perhaps it is because the 'dataset'
object is itself an entry in one of the table columns (presenting
the string generated by the default 'description' method). Either
way, this is detrimental to performance and memory footprint since
these objects are huge (and I wouldn't normally have expected or
wanted them to be copied).
Is there any way to control this behavior, for example forcing the
actual object to be used instead of these transient copies?
Failing that, I am wondering (yes, I know this is ugly) if there is
a way to set up some kind of context flag so that my object's 'copy'
methods will just return a lightweight proxy when being called in
this kind of situation (copied as part of a dictionary that is
itself being copied)? The 'dataset' object implements both mutable
and immutable copying. It is the 'immutable' copy method that is
called during table scrolling.
It's not the table view's fault.
What generates the description for the data set? You wrote a
'description' method? How long is the string it returns?
If the property to which a table column is bound has the "copy"
attribute, then the value will indeed be copied every time the table
view fetches a value for the column. Does you "large dataset object"
support NSCopying? However, since you've chosen to use dictionary
instead of real properties, this seems unlikely to be the cause of
your problem, unless there's more you haven't told us.
My bet's on a giant description string the size of Manhattan.
_______________________________________________
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
