On Jul 2, 2012, at 3:28 PM, Charles Srstka wrote: > NSInteger is always equal to the native integer size of the host machine; 32 > bits in 32-bit, 64 bits in 64-bit. I would imagine this helps performance, as > the processor will be dealing with its native integer type.
It depends. 64-bit values are twice as big as 32-bit ones, so they use up twice as much L2 cache and RAM. That's often a bigger consideration than the CPU overhead, which might be zero, of extending values in registers. (Most of the time performance is not about how many clock cycles your code uses, it's about how many bytes of RAM it uses.) > And really, if you are storing NSUIntegers to the disk, you’re just doing it > wrong. I agree. My comment was in response to Chris's about NSIntegers being good for persistent storage. It didn't make sense to me either. > XML is what you should be using for most new formats these days; Hey, 1999 called and wants its trendy data format back! No one but squares uses XML anymore; JSON is what's hep. ;-) > when you have to read/write in binary formats, that’s what the u?int[0-9]+_t > formats are for. Using a uint32_t in cases where there’s no real reason to > require that the integer be exactly 32 bits wide, though, doesn’t seem to > provide any benefit. It's useful when you explicitly _don't_ want a 64-bit value, to save space. —Jens _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
