JDK-8131909 : Also use 'fastPath' in DecimalFormat for integers
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 8u51
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_8
  • CPU: x86
  • Submitted: 2015-07-16
  • Updated: 2019-04-11
Related Reports
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
A while back, JDK8's DecimalFormat got a fast path for the most common formatting case of doubles (in JEP-177 and/or report JDK-7050528).

For double's this yields a significant performance boost when certain common conditions are met. The DecimalFormat has to be configured with a specific set of standard configuration parameters (the defaults for a large part of the world) and the provided double's integral parts have to be any regular 32 bit integer (except Integer.MIN_VALUE).

That works pretty good.

What surprised me, is that such a fast path is not used for actual 32-bit integers. So calling numberFormat.format(someInt) is much slower than numberFormat.format((double)someInt).

This method: DecimalFormat.format(long number, StringBuffer result,                               FieldPosition fieldPosition)

could be enhanced by a similar test as already found in its double counterpart for any long which fits inside the range (Integer.MIN_VALUE, Integer.MAX_VALUE]

Alternatively a specific fast path method for integers could be created, which doesn't have to bother with a fractional part since there won't be one.

I also think there is no specific need for the fast path to work with integers, it could also work with longs (see DecimalFormat.collectIntegralDigits). That would allow the fast path for any long, rather than just the 32 bit ones. It would also allow a much wider range of double's to be processed via the fast path. Although I have no idea what cost that has for the performance (it will require 64-bit aritmetic rather than 32-bit, and needs several long 2 int conversions for the array-accesses).

JUSTIFICATION :
I think the fast path ought to be used for actual integers, since its designed to improve the performance of the doubles that fit in the 32-bit integer ranges already (and actually works by casting the double to an int).

It gives a pretty nice performance boost for double's and the integers fit the same criteria by their very definition.


CUSTOMER SUBMITTED WORKAROUND :
Currently, (almost) the same performance can be achieved by casting a int to a double and having DecimalFormat work on that. For that specific standard configuration that should work... but it is likely a bit dangerous with all the other possible configurations.