3

When you have to deal with numbers for anything else than short computation, is it a loss of time and energy using always NSNumber ?

What's the best approach ?

mskfisher
  • 3,291
  • 4
  • 35
  • 48
Oliver
  • 23,072
  • 33
  • 138
  • 230

4 Answers4

4

When you have to deal with numbers for anything else than short computation, is it a loss of time and energy using always NSNumber?

Well, NSNumber generally has to go through the allocation and reference counting hoops to create, so that takes a lot longer than creating a float on the stack.

As well, NSNumber is an immutable type, so it doesn't make a whole lot of sense to set it often because every time it changes, you have to allocate a new instance. There are a few optimizations they make, but it's still huge overhead relative to creating a float on the stack. Using builtins will also require less memory than NSNumber more often than the other way around.

What's the best approach?

I just use builtins (e.g. float, int) unless I need an NSNumber. Details and rationale here.

Community
  • 1
  • 1
justin
  • 104,054
  • 14
  • 179
  • 226
  • 2
    Yes, but the OP asks about `NSInteger` and `CGFloat` also... NSInteger is typedef'd to `int` on 32-bit and `long` on 64-bit architectures. CGFloat is typedef'd to `float` on 32-bit and and `double` on 64-bit. So using `CGFloat` and `NSInteger` has the advantage that you automatically get the most optimal precision per platform. (iOS is currently 32-bit, and although double-precision is supported [it is slower](http://stackoverflow.com/a/1622786/172218)). If you require a fixed integer precision it's better to use types such as `uint16_t` from [stdint.h](http://en.wikipedia.org/wiki/Stdint). – j b Aug 14 '12 at 11:06
1

Use whichever is appropriate to your task.

For example, if you are computing rects for drawing use CGFloat because that is what rects use.

NSNumber on the other hand is really good for situations where you need multiple representations of a number (i.e., you need to use it a float and an int).

sosborn
  • 14,676
  • 2
  • 42
  • 46
  • OK, but imagine I have to store that float (used for rects). Is it best to work with a NSNumber and convert it to a CGFloat when needed, or work with a CGFloat and convert it to a NSNumber when stored in a plist ? – Oliver Nov 09 '11 at 01:52
  • 1
    In that case I would store it as an NSNumber. How you use the NSNumber would depend on your code, but as a general rule of thumb I don't like doing a lot of [myNumber floatValue] so I would probably create a CGFloat variable from [myNumber floatValue] and then use that in the method. Use whatever is best for you (considering readability, maintainability,etc). Performance-wise it is not likely to make any difference (profile if you suspect that it does) so it really comes down to preference. – sosborn Nov 09 '11 at 02:28
1

NSInteger, NSUInteger, CGFloat, etc are simple types and correspond to int, unsigned int and float. NSNumber is an Objective-C class, a subclass of NSValue to be specific. You can create an NSNumber object from a signed or unsigned char, short int, int, long int, long long int, float, double or BOOL.
One of the primary distinctions is that you can use NSNumber in collections, such as NSArray, where an object is required. NSInteger is a simply an integer, NSNumber is an object.
For performance reasons, if you can, use primitive types (like int, float). However, sometimes you cannot avoid NSNumber,

Parag Bafna
  • 22,812
  • 8
  • 71
  • 144
0

Using NSInteger & CGFloat allows your code to run properly on all architectures, 32/64-bit. If you used int/float and compiled your code for a 64-bit architecture, it likely would not operate correctly on a 32-bit system. Additionally, if Apple ever released a 128-bit system your NSInteger/CGFloat code would still work there too (assuming Apple updated the definitions of NSInteger & CGFloat, which they likely would).

Yes, it's a significant loss of time always using NSNumber

kcwaverider
  • 31
  • 2
  • "If you used int/float and compiled your code for a 64-bit architecture, it would not run on a 32-bit system.": the code will run. You may get warning and even unwanted behavior, but it will run. – Christian Garbin Jun 28 '15 at 23:19