JDK-6801512 : Further performance enhancement for BigDecimal.toString()
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.math
  • Affected Version: 6u14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-02-05
  • Updated: 2013-11-01
  • Resolved: 2009-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u14 b03Fixed 7Fixed
Related Reports
Relates :  
There are several places we can do in java.math.BigDecimal to improve the performance. One thing we can do in toString implementation is to associate the temporary character array for placing the intCompact with the thread local StringBuilder object. That way, we can avoid:
1. Calculating the digit length of the intCompact if we just make it to hold the biggest possible intCompact which needs 19 character.
2. Avoid repeatedly creating small temporary array objects.

Two other places we can shorten the code path and avoid expensive operations are:

1. BigDecimal.compareTo method, if this object and the comparing object has the same scale and both of them are compact, we can just do comparison and return. Intel folks measured about 0.5 - 1% improvement in SPECjbb2005.
2. BigDecimal.multiply method, in the overflow check, we can test whether both of the intCompact field are less than Integer.MAX_VALUE before do expensive division check.

EVALUATION The fix was actually described in the comments section.