Hello all
On December 1, 2010, "darcy" committed a slight performance improvement to the
StrictMath.min/max methods with floating point arguments (commit 8aabca72877c).
The calls to the doubleToLongBits(double) method were replaced by calls to the
doubleToRawLongBits(double) method, and similarly for the float type. Since the
call to doubleToLongBits was used only in order to determine if an argument was
negative zero, and since NaN can not map to the bits pattern of -0.0, the extra
cost of collapsing all NaN values to a single canonical NaN (which is the only
difference between doubleToLongBits and doubleToRawLongBits) was unnecessary.
However this improvement has not been ported from StrictMath to Math; the more
widely-used Math class still invokes the (presumed) slower
doubleToLongBits(double) method. Actually it appears that most Math / StrictMath
method implementations delegate to the other class: some Math methods delegates
to StrictMath (mostly the methods backed by native code), and some StrictMath
methods delegate to Math (mostly the methods implemented in pure-Java). The
min/max methods are an exception; their implementation is copied in both
classes. Maybe this explain why the code was updated in only one class and not
the other?
In the patch submitted below, I propose the following changes:
1) Ported the doubleToLongBits --> doubleToRawLongBits changes from StrictMath
to Math.
2) Replaced StrictMath implementations by calls to Math, in order to reduce the
risk that the code of only one class is updated in the future.
3) In if statements, replaced:
(a == 0.0d) && (Double.doubleToLongBits(a) == negativeZeroDoubleBits)
by
(Double.doubleToLongBits(a) == negativeZeroDoubleBits)
since the later implies the former.
4) Moved the check for (a != a) from the method beginning to the last statement,
which is tested only if (a <= b) were false rather than tested unconditionally
in every cases. I'm not sure if it make a real performance difference however.
Webrev link: http://webrev.geomatys.com/Math/min_max/index.html
Regards,
Martin
