On Sat, Jul 12, 2008 at 2:25 AM, Marcel Weiher <[EMAIL PROTECTED]> 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 (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 [EMAIL PROTECTED]
