• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CFDictionary callback on PPC vs Intel
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CFDictionary callback on PPC vs Intel


  • Subject: Re: CFDictionary callback on PPC vs Intel
  • From: "Derrek Leute" <email@hidden>
  • Date: Sun, 17 Feb 2008 13:40:25 -0500

This is excellent to know. What about performance? Performance is
*very* important in this case. A 1% increase can knock hours or days
off of processing time on this size data set. Any performance metrics
available?

--Derrek

On Feb 17, 2008 11:54 AM, glenn andreas <email@hidden> wrote:
>
> On Feb 17, 2008, at 10:43 AM, 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.
>
> Close but not quite exactly correct.
>
> NSDictionary requires that keys conform to the NSCopying protocol
> because it make a copy of the key (regardless of if it is an NSString,
> or whatever).  The important part is that for a non-immutable
> NSString, it will simply increase the reference count - no increase in
> the memory usage at all.  If you pass an NSMutableString as a key, it
> will make a (immutable) copy that does, in fact, increase memory usage.
>
> You may wonder why it does this - consider this:
>
> NSMutableString *s1 = [NSMutableString stringWithString: @"abc"];
> NSMutableString *s2 = [NSMutableString stringWithString: @"def"];
> NSMutableDictionary *d = [NSMutableDictionary dictionary];
>
> [d setObject; [NSNumber numberWithInt: 1] forKey: s1];
> [d setObject: [NSNumber numberWithInt: 2] forKey: s2];
> [s1 setString: @"def"];
>
> NSLog(@"%@", [d objectForKey: @"def"]);
>
> If it didn't make an immutable copy, you would end up with two values
> that both have the key "def".
>
> So, if you use immutable objects as keys, your memory usage won't go
> up.  If you use mutable objects as keys, it will make a copy because
> if it didn't, bad things would happen.
>
>
> Glenn Andreas                      email@hidden
>   <http://www.gandreas.com/> wicked fun!
> quadrium | prime : build, mutate, evolve, animate : the next
> generation of fractal art
>
>
>
>
_______________________________________________

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

References: 
 >CFDictionary callback on PPC vs Intel (From: "Derrek Leute" <email@hidden>)
 >Re: CFDictionary callback on PPC vs Intel (From: "Michael Ash" <email@hidden>)
 >Re: CFDictionary callback on PPC vs Intel (From: "Derrek Leute" <email@hidden>)
 >Re: CFDictionary callback on PPC vs Intel (From: glenn andreas <email@hidden>)

  • Prev by Date: re: CoreData Performance Mystery
  • Next by Date: Re: @property problem
  • Previous by thread: Re: CFDictionary callback on PPC vs Intel
  • Next by thread: Re: CFDictionary callback on PPC vs Intel
  • Index(es):
    • Date
    • Thread