1

I have a Java project that deals with a lot money values and the project mainly involves:

  • reading the data from database,
  • calculations (process data)
  • showing to users (no inserts or updates in database are required).

I need precision for only some of the money values and not for all. So here I can do:

  1. using doubles when precision not required or
  2. using BigDecimals for ALL.

I want to know if there will be any performance issues if I use BigDecimal for all the variables? Can I save execution time if I opt for choice 1? Which way is best? (I am using java 6)

The Guest
  • 698
  • 11
  • 27
  • 2
    NEVER USE DOUBLES FOR MONEY – dkatzel Sep 29 '15 at 15:55
  • 2
    possible duplicate of [Double vs. BigDecimal?](http://stackoverflow.com/questions/3413448/double-vs-bigdecimal) – bvdb Sep 29 '15 at 15:55
  • Money datatypes in java: http://www.javapractices.com/topic/TopicAction.do?Id=13 – bvdb Sep 29 '15 at 15:57
  • In Java 9, there will be JavaMoney API with JSR 354. – Tunaki Sep 29 '15 at 15:58
  • So, mostly if I am reading the data and not doing many calculations then I can use either BigDecimal or Double, right? I am not doing many calculations or roundings, using BigDecimal can't effect execution time. Because bigdecimal consumes more time when it is involved in caculations or roundings???? – The Guest Sep 29 '15 at 16:08
  • I don't think its a duplicate of http://stackoverflow.com/questions/3413448/double-vs-bigdecimal. I already read it. But I couldn't get the answer suitable for my project. Please refer my previous comment – The Guest Sep 29 '15 at 16:09

3 Answers3

3

Don't use double for money Why not use Double or Float to represent currency?

Using Big Decimal is 100x slower than the built in primitives and you can't use + and -, / and * with BigDecimal but must use the equivalent BigDecimal method calls.

An alternative is to use int instead of double where you are counting cents or whatever fractional currency equivalent and then when formatting the output to the user, do the appropriate conversions back to show the values the way the user expects.

If you have really large values, you can use long instead of int

Community
  • 1
  • 1
dkatzel
  • 31,188
  • 3
  • 63
  • 67
2

It's a trade-off.

With BigDecimal you are working with immutable objects. This means that each operation will cause the creation of new objects and this, for sure, will have some impact on the memory. How much - it depends on a lot of things - execution environment, number and complexity of the calculations, etc. But you are getting precision, which is the most important thing when working with money.

With double you can use primitive values, but the precision is poor and they are not suitable for money calculation at all.

If I had to suggest a way - I would say for sure use BigDecimal when dealing with money.

Have you considered moving some of the calculation logic to the DB layer? This can save you a lot in terms of memory and performance, and you will still keep the precision requirement in tact.

Danail Alexiev
  • 7,624
  • 3
  • 20
  • 28
2

BigDecimal and double are very different types, with very different purposes. Java benefits from having both, and Java programmers should be using both of them appropriately.

The floating point primitives are based on binary to be both space and time efficient. They can be, and typically are, implemented in very fast hardware. double should be used in contexts in which there is nothing special about terminating decimal fractions, and all that is needed is an extremely close approximation to a value that may be fractional, irrational, very big, or very small. There are good implementations of many trig and similar functions for double. See java.lang.Math for some examples.

BigDecimal can represent any terminating decimal fraction exactly, given enough memory. That is very, very good in situations in which terminating decimal fractions have special status, such as many money calculations.

In addition to exact representation of terminating decimal fractions, it could also be used to get a closer approximation to e.g. one third than is possible with double. However, situations in which you need an approximation that is closer than double supplies are very rare. The closest double to one third is 0.333333333333333314829616256247390992939472198486328125, which is close enough for most practical purposes. Try measuring the difference between one third of an inch and 0.3333333333333333 inches.

BigDecimal is a only supported in software, does not have the support for mathematical functions that double has, and is much less space and time efficient.

If you have a job for which either would work functionally, use double. If you need exact representation of terminating decimal fractions, use BigDecimal.

Patricia Shanahan
  • 25,849
  • 4
  • 38
  • 75