Re: CFDictionary callback on PPC vs Intel
Re: CFDictionary callback on PPC vs Intel
- Subject: Re: CFDictionary callback on PPC vs Intel
- From: Quincey Morris <email@hidden>
- Date: Sun, 17 Feb 2008 12:05:13 -0800
On Feb 17, 2008, at 08:43, Derrek Leute wrote:
The project actually started in cocoa but I moved to CF because
NSDictionary forces a string copy for keys. This made memory needs go
through the roof (unless I'm misusing or misunderstanding how to use
it). CF lets me use anything as a key. In some sense I would love to
be in Cocoa as I had to reimplement NSSet intersection and some other
little basic things to do this. But it's fast, and it seems to be
working quite well now. Not to mention that pointer comparison also
seemed ridiculously faster on this amount of data.
Sorry if I'm being dense here, but I don't see how it's NSDictionary's
fault. NSDictionary is only going to copy the key when you insert
something, and (as somebody already pointed out) if the key string is
immutable there may be no actual copying.
It looks like the real problem is that you're creating a large number
of temporary objects (the strings you use to look up the dictionary)
with a lifetime of 1 loop iteration, but doing nothing to reclaim the
unused memory (in the code snippet you showed us, at least). Judicious
use of GC's collectIfNeeded might take care of that.
The reason CFDictionary seems to work better is nothing to do with
string copying per se. It's actually that innocent-looking CFRelease,
which reclaims the memory you used for the temporary string at each
iteration of the loop. In effect, you've switched from GC to pseudo-
non-GC mode for the duration of the loop. :) That's why memory usage
stays moderate.
_______________________________________________
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