Re: garbage collection and NSConnection
Re: garbage collection and NSConnection
- Subject: Re: garbage collection and NSConnection
- From: "Michael Ash" <email@hidden>
- Date: Sat, 12 Jul 2008 11:25:15 -0400
On Sat, Jul 12, 2008 at 2:25 AM, Marcel Weiher <email@hidden> wrote:
>
> On Jul 11, 2008, at 12:53 , Michael Ash wrote:
>
>>
>> Seems that NSString and NSMutableString are just faster at everything.
>> In all cases, the cost of an extra retain/release for them is still
>> roughly 50% of the cost of an alloc/init/retain. Here are my raw
>> numbers, times in nanoseconds:
>>
>> [timings snipped]
>
>>
>> I have no explanation as to why NSMutableString is so much slower at
>> everything.
>
> I do ;-)
>
>> They both end up creating an instance of NSCFString, so
>> this is puzzling. But there you are.
>
> These sorts of tests can be tricky to get right: of the two, only the
> NSMutableString test is creating strings for you, your NSString test is just
> returning the same empty+constant string over and over (you can verify this
> by printing the object pointer). You can control for this, for example by
> using -initWithCString: with a buffer whose contents change slightly each
> time.
>
> These are the numbers I get:
>
> NSMutableString alloc+init(WithCString:) + release(/dealloc) : 1246
> nanoseconds
> NSMutableString alloc+init(WithCString:) + release(/dealloc)
> +retain/release: 1365 nanoseconds
> NSString alloc+init(WithCString:) + release(/dealloc) : 418 nanoseconds
> NSString alloc+init(WithCString:) + release(/dealloc) +retain/release: 527
> nanoseconds
>
> In both cases, the extra retain/release costs around 110ns, so allocation
> is 4x to 10x slower. (I have to admit the 4x surprises me a little bit, in
> my experience that value was higher).
>
> The reason NSMutableString is slower is that it needs to allocate an extra
> buffer. NSString is pretty heavily optimized, it takes just as long to
> allocate as does an empty NSObject:
>
> NSObject alloc+init+release(/dealloc): 417 ns
>
> But of course the retain/release for NSObject is much more expensive:
>
> NSObject alloc+init+release(/dealloc) + retain/release: 740 ns
> NSObject alloc+init+release(/dealloc) + 2x retain/release: 1026 ns
>
>
> So as I said: (a) object allocation slowest (b) out-of-band retain count
> slow (c) inline retain count much faster than either.
Well that all makes sense, thanks.
One further question for you, if you will. I got curious and went off
hunting for the inline refcount in NSCFString but couldn't find it.
The closest I got was the '_rc' field in CFRuntimeBase, but it's
inside an #if __LP64__ clause, so we don't get it in normal code these
days. The __CFString struct doesn't seem to have any place to store a
refcount. Am I missing something here, or does it only have an inline
refcount in 64-bit?
Mike
_______________________________________________
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