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

Details
Type:
Enhancement
Submit Date:
2007-10-27
Status:
Resolved
Updated Date:
2014-02-20
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 (b01)

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

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

See comments for details of the fix.
                                     
2007-10-29
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

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



Hardware and Software, Engineered to Work Together