Re: CFDictionary callback on PPC vs Intel

FROM : Quincey Morris
DATE : Sun Feb 17 21:05:13 2008

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.