On 06/03/2010 01:57 PM, Charles Oliver Nutter wrote:
Wow, I'd be very surprised if that's true. Big(Integer/Decimal) are
enormous compared to a long, especially on 64-bit JVM, so at a minimum
you have the allocation cost of all that extra data.
BigInteger has the following fields:
bitCount, bitLength, lowestSetBit, firstNonzeroIntNum
These are all deprecated (in the jdk7 source. at least), and are
just seldomly-used (?) caches, so could reasonably be removed.
The actual data:
int signum
int[] mag
If mag was changed to use 2's complement (as gnu.math.IntNum does)
then one could rid of signum, leaving just the (renamed) mag field.
Better of course would be to use the gnu.math.IntNum mechanism
of two fields:
public int ival;
public int[] words;
In this case words==null is treated as an optimization of
the case when words.length<=1.
I think this would be a very worthwhile optimization.
Less work and almost as good would be to keep using
signed-magnitude representation in the bignum case,
and merge the signum field with the fixnum optimization.
And add to that the fact that even on 32-bit, math
operations against long are always going to be faster than those
against a byte[] in Big(Integer/Decimal).
Actually, it's an int array. (It gets converted to/from a byte
array during serialization.)
--
--Per Bothner
[email protected] http://per.bothner.com/
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
