[I wrote most of this before seeing Paul C's response, but got distracted before I finished it. Now some of it is redundant, but much is not. Just ignore the parts that duplicate Paul's response, please.]
Well, it's all relative. BigDecimal is almost certainly much slower than corresponding calculation using float or double would be - but very, very often, this is still much faster than you really need it to be, so who cares? This is also true of memory usage, incidentally. BigDecimal uses more memory, but this often isn't enough more memory to be worth worrying about. This is probably a case of premature optimization. It's usually best not to worry to much about this sort of thing until you have a working program that does what you need it too, and where you can measure how much time and memory it's using, and whether that is a problem.
However there are some cases where you know in advance that you will be doing a lot of computations, and you have good reason to believe that computational speed will be a primary concern. In such cases it may be better to start out using primitives for all calculations, and only move to BigDecimal after you've verified that you really need it for some reason.
And it's worth considering: why do you need (or think you need) BigDecimal, at all? In my experience many applications that "need" BigDecimal don't, really. There are two primary reasons I know for using BigDecimal, and both can be handled by alternate strategies:
1. When people see results like 4.999999999997 when they expect to see 5, they become emotionally upset. The ideal solution here would be to give everyone better math education so they stop whining about this sort of thing. However that's not really practical from the programmer's point of view. Too bad. Instead, programmers should need to learn to use methods like String.format(), and sometimes Math.round(), Math.ceil(), and Math.floor(), to convert results to something less upsetting to casual viewers.
2. Some quantities, most commonly money values, must be converted to discrete well-defined values, usually with a nice finite number of digits after the decimal. Usually the same effect can be achieved with ints, or better, longs. You just need to move the decimal point. For a value of $123.45, don't store it as a float or double of 123.45. Or a BigDecimal of 123.45. Instead, store it as a long of 12345, and do all of your money calculations in cents, not dollars. You may occasionally need to use rounding functions (what if a shipping cost needs to be pro-rated across 3 identical items, by dividing by 3?). But that's true using BigDecimal as well - at some point, you may need to decide how to round things off properly. And if you ever have a problem where a long is not big enough to contain the number of cents you need to calculate... well, send me a private message; I'm sure I can help out. For a suitable fee.
the thing is I have a 2 dimenstional array that consists of fractions between 0 and 1. What's worse is that i'm multiplying those numbers together. Sometimes hundreds of times. So I may het a numbe that is 1.44e-60, which double just can't take care of. So it's not just the rounding thing. I guess a double can hold values as low as 2-1074, but I'm deeply skeptical since I need to multiply, divide and add a lot.
It really looks like something I can handle in double....I guess I'll write a few programs to test it out.
Hm, offhand it sounds like something double will have no problem with. There are some types of formulas that are more susceptible to numeric errors, but those are also the ones that will make BigDecimal very, very slow.
Remember that with BigDecimal, every time you divide you need to decide the scale of the result. How many significant digits do you want to retain? Fundamentally, even BigDecimal can't represent 1/3 accurately, so you would need to decide if you want 0.33333, 0.333333333333, or 0.33333333333333333333333333333333333333333333. The more digits you use, the more memory you use, and the slower everything gets. Whereas by using double, you mostly ignore this issue and still get an answer that's "good enough", almost always.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop