Performace of BigDecimal vs. BigInteger and BigDec

Question

I was debating whether to use BigDecimal and BigInteger or only BigDecimal to make my life easier and less converting back and forth. Is there a downside to only using BigDecimal in regards to resources?

How about using only primitive data types and BigInteger or only BigInteger to make my life easier and less converting back and forth?

Answer 1

I know the title of your question states "Performace of BigDecimal vs. BigInteger and BigDecimal" but one of your questions states "How about using only primitive data types and BigInteger or only BigInteger to make ". Well here is what I recommend:

If you need accuracy, precision and you have large numbers to work with such as huge financial data then it may be best to use BigDecimal and BigInteger instead of primitive types. Few other characteristics of BigDecimal and BigInteger are also:

1. Both are from immutable objects.
2. Both extend from Number class and implement comparable interface

Now back to your main question in terms of performance, there is not much of difference in terms of performance between the two. If you can present your information in BigDecimal just use that so you don't have to convert it over to BigInteger but again look at the program and see if it does make sense to only use BigDecimal all the time. The main difference between the BigInteger and BigDecimal is that BigInteger supports arbitrary-precision integers and BigDecimal is for arbitrary-precision fixed-point numbers.

Here are my sources and good luck :)

NY University

Colorado University

Answer 2

If you are developing a low-latency application and every microsecond matters, BigDecimal/BigInteger is not for you. Besides this fact BigDecimal/BigInteger has no visible impact.

BigDecimal does preform lower than long, double. The same apples to BigInteger and its corresponding primitives.

Answer 3

If you're worried much about performance with big numbers, I'd avoid Java's BigInteger and BigDecimal like the plague.

Both use slow (both asymptotically and on reasonably small inputs) algorithms for multiplication, division, and radix conversion. You have no way to replace them with more efficient algorithms if it turns out to be a bottleneck, short of coding up your own BigInteger-compatible big-numbers and doing a big refactor.

You're probably much better off using a Java wrapper around GMP and MPFR if you're dealing with large integers. "Large" here might be a couple hundred digits because of the things Java does when you call native methods.

Answer 4

From: http://www.javamex.com/tutorials/math/BigDecimal_BigInteger_performance.shtml

Note that a BigDecimal is essentially a wrapper around a BigInteger that "remembers where the decimal point is".

Because of the way we are used to dealing with numbers, as humans, we may have to "think a bit more" when calculating with non-integers by hand compared to integers (e.g. we may have learnt the 7 times table by heart to speed up certain calculations, but probably not the .7 times table). But to a computer implementation, it is essentially no more effort to manipulate non-integers than it is integers, and so on the whole, methods on BigDecimal tend to perform similarly to analogous methods on BigInteger.