Re: holding NSMutables in non-mutable instances
Re: holding NSMutables in non-mutable instances
- Subject: Re: holding NSMutables in non-mutable instances
- From: Greg Titus <email@hidden>
- Date: Fri, 12 Oct 2001 13:28:43 -0700
On Friday, October 12, 2001, at 12:52 PM, John Timmer wrote:
A quick technical question:
My understanding is that NSMutable class instances carry a bit of
overhead
in terms of memory and processing time due to their added flexibility,
so
that if you're going to finalize a bunch of them, it's worth converting
them
to an unmutable form.
Just in terms of memory, usually. For instance, an NSMutableArray may
have some 'blanks' allocated beyond the existing objects to make
additions more efficient. But access time for getting at elements in the
array isn't going to be different between the mutable and non-mutable
versions.
Given that, the question: if I pass an NSMutable to another NSMutable,
then
convert the second one to a non-mutable, does that convert the first
to a
non-mutable? A concrete example: I stuff an NSMutableDictionary into
an
NSMutableAttributedString, then convert that to an NSAttributedString.
Is
there still some cost associated with the dictionary, or is it
automagically
converted for me?
No. The mutable dictionary hasn't changed.
An alternate question: Am I thinking too much about this?
Yes, probably. :-)
Beware premature optimization! If you write your app/framework/whatever,
profile the memory usage with a tool like ObjectAlloc, and find that you
have hundreds or thousands of mutable objects that (a) never change, (b)
are accessed relatively often (enough that they are usually taking up
RAM or swapping in and out, rather than just sitting quiescent in the
swap file), and (c) are around for a long time, _then_ you might
consider doing something about it.
Without (a) you should keep the objects mutable. Without (b) and (c) the
cost of making the non-mutable copy is likely to be more expensive than
just leaving them as is.
Hope this helps,
--Greg