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.