United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6622432 RFE: Performance improvements to java.math.BigDecimal
6622432 : RFE: Performance improvements to java.math.BigDecimal

Details
Type:
Enhancement
Submit Date:
2007-10-27
Status:
Resolved
Updated Date:
2010-12-02
Project Name:
JDK
Resolved Date:
2009-01-30
Component:
core-libs
OS:
generic,solaris_nevada,windows_xp
Sub-Component:
java.math
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6,7
Fixed Versions:
6u14

Related Reports
Backport:
JDK-2172334 - RFE: Performance improvements to java.math.BigDecimal
Backport:
JDK-2202264 - RFE: Performance improvements to java.math.BigDecimal
Duplicate:
JDK-6832035 - BigInteger and MutableBigInteger should use Integer bit-twiddling methods
Duplicate:
JDK-6348370 - java.math.BigInteger is *not* thread-safe immutable
Relates:
JDK-6876282 - BigDecimal's divide(BigDecimal bd, RoundingFormat r) produces incorrect result
Relates:
JDK-6806261 - BigDecimal.longValueExact() method throws NullPointerException
Relates:
JDK-6838776 - Defer initialization of static fields in java.math.BigInteger
Relates:
JDK-6819773 - BigDecimal.divide(BigDecimal,int,int) throws ArrayIndexOutofBoundsException under some circumstances
Relates:
JDK-2169668 - java.math.BigInteger.ZERO.multiply(null)
Relates:
JDK-6837951 - Incorrect answer while summing serialized / deserialized BigDecimals

Sub Tasks

Description
The profiling results from running derby benchmark inside SPECJvm2007 shows significant performance issue in our implementation of BigDecimal code. Here are couple hot methods showing inside both Sun & other profiling tools:

*setScale
*precision
*BigDecimal(...) /* various constructors. */

The other data point from some low level profiling tool shows we have significant higher number of division/multiplication operations than some of our competitors.

Comments
EVALUATION

One of the changes for the BigInteger improvement is to remove the implicit initialization for a few of fields such as "bitCount", "bitLength" & "lowestSetBit". The removal of initialization for "lowestSetBit" will affect the largest BigInteger values people working with theoretically. Generally speaking, BigInteger wasn't designed to handle such case, but standing on the cautious side is always good,  so I am going to file a CCC request to cover that.
2008-11-21 
EVALUATION

I have a webrev at http://javaweb.sfbay/~xl116366/webrev/bigdecimal_opt for review. To ease future reference, here are some highlights for the changes which affect the performance significantly.

1. Make TENPOWERS array to be expandable so that we don't have to construct BigInteger of ten's power repeatedly. The default maximum size of the array is 304 which means it can hold up to 10**303.

2. Make digitLength to work efficiently by avoiding division operation which is generally considered as expensive. Use the TENPOWERS array which is now expandable, we can now apply the same trick for computing the integer length to these big integers.

3. Clean up MathContext to avoid creating unnecessary BigInteger objects, drop "dropDigits".

4. Have a trusted version of divide method to avoid repeatedly roundingMode checks.
2007-12-07 
EVALUATION

See comments for details of the fix.
2007-10-29


Hardware and Software, Engineered to Work Together