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  customer . 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  customer  and the comparing  customer  has the same scale and both of them are compact, we can just do comparison and return.  customer  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.
Posted Date : 2009-02-05 00:59:03.0

N/A

The fix was actually described in the comments section.
Posted Date : 2009-02-05 01:00:59.0