>> NSNumber.numberWithFloat(10.1)+NSNumber.numberWithInt(2)+1
=> 13.1000003814697
>> NSNumber.numberWithFloat(10)+NSNumber.numberWithInt(2)-0.1
=> 11.9
>> 1+NSNumber.numberWithInt(10)+NSNumber.numberWithInt(2)
=> 13
Basically, unless there is a very simple operation being done (with no sharp edge cases that I was uncertain about), it converts itself into a ruby object or pseudo-object and passes itself directly to the C implementations of the appropriate ruby methods. This probably performs better than keeping it as a CFNumber, since a CFNumber's value would need to be fetched and a new CFNumber would need to be reallocated for every operation (and I believe the ruby equivalents are quite a bit cheaper).
Current ("ruby") solution:
1 CFNumber value fetch (2 C calls) for each OC->RB crossing (no double-dispatch penalty, it sends the new object right to the C functions)
1 RFixnum allocation for each RB->OC crossing
Cheap numeric operations (no allocations in the good case, at worst it's probably the same as objc)
Complete NSNumber conversion ("objc" solution):
1 CFNumber value fetch for each numeric operation
1 CFNumber allocation for each numeric operation
Using FIXABLE() numbers, both solutions should approximately tie for 1-step arithmetic. But in every other case, the ruby solution should be faster, and it has the advantage of already being implemented :-)
It just occurred to me that I left out method dispatch overhead. You're the expert on that, so you tell me how it weighs in here :)
I would love to see something like FScript's operator methods ('+' maps to 'add:', and the like). Would using objc_msgSend make it worth the allocation overhead?
For compatibility reasons, a complete overhaul of the FIXNUM system probably wouldn't be very practical: any "regular" ruby C API code would still use the FIXNUM interface, so you would have to keep it around even if you replaced it with something more elegant under the hood. Unless there are secret plans I don't know about :)