Why is Java's Math.min so slow in my Android app?

Question

I had some code I was profiling and was surprised at how much time was being spent on Math.min(float, float).

In my use case I needed to get the min of 3 float values, each value is guaranteed to not be NAN or another edge case float value.

My original method was:

private static float min2(float v1, float v2, float v3) {
    return Math.min(Math.min(v1,v2),v3);
}

But I found that this was about 5x faster:

private static float min1(float v1, float v2, float v3) {
    if (v1 < v2 && v1 < v3) {
        return v1;
    }
    else if (v2 < v3) {
        return v2;
    }
    else {
        return v3;
    }
}

For reference this is the code for Math.min:

public static float min(float f1, float f2) {
    if (f1 > f2) {
        return f2;
    }
    if (f1 < f2) {
        return f1;
    }
    /* if either arg is NaN, return NaN */
    if (f1 != f2) {
        return Float.NaN;
    }
    /* min(+0.0,-0.0) == -0.0 */
    /* 0x80000000 == Float.floatToRawIntBits(-0.0f) */
    if (Float.floatToRawIntBits(f1) == 0x80000000) {
        return -0.0f;
    }
    return f2;
}

Note: My use case was symmetric and the above was all true for max instead of min.

EDIT1: It turns out ~5x was an overstatement, but I am still seeing a speed difference inside my application. Although I suspect that may be due to not having a proper timing test.

After posting this question I wrote a proper micro optimization speed test in a separate project. Tested each method 1000 times on random floats and they both took the same amount of time. I don't think it would be useful to post that code as it's just confirming what we all already thought.

There must be something specific to the project I'm working on causing the speed difference.

I'm doing some graphic work in an Android app, and I was finding the min/max of the values from 3 touch events. Again, edge cases like -0.0f and the different infinities are not an issue here. Values range between 0.0f and say 3000f.

Originally I profiled my code using the Android Device Monitor's Method Profiling tool, which did show a ~5x difference. But, this isn't the best way to micro-profile code as I have now learned.

I added the below code inside my application to attempt to get better data:

long min1Times = 0L;
long min2Times = 0L;
...
// loop assigning touch values to v1, v2, v3
        long start1 = System.nanoTime();
        float min1 = min1(v1, v2, v3);
        long end1 = System.nanoTime();
        min1Times += end1 - start1;
        long start2 = System.nanoTime();
        float min2 = min2(v1, v2, v3);
        long end2 = System.nanoTime();
        min2Times += end2 - start2;
        double ratio = (double) (min1Times) / (double) (min2Times);
        Log.d("", "ratio: " + ratio);

This prints a running ratio with each new touch event. As I swirl my finger on the screen, the first ratios logged are either 0.0 or Infinity or NaN. Which makes me think this test isn't very accurately measuring the time. As more data is collected the ratio tends to vary between .85 and 1.15.

Answer 1

The problem is about the precision of float values.

If you would call your method with the arguments (0.0f, -0.0f, 0.0f), it will return you 0.0f to be the smallest float - which it isn't (float-wise, -0.0f is smaller)

the nested Min-Method will return the expected result.

So, to answer your question: If two methods are not 100% equal - there is no point in comparing their performance :-)

Java will handle 0.0f == -0.0f as true, but: new Float(0.0)).equals(new Float(-0.0)) will be false! Math.Min will consider this, your method not.

When working with float values, you should never use smaller or equal to operators. Instead you should compare numbers based on your preselected delta to consider them smaller, greater or equal.

float delta = 0.005
if (Math.abs(f1 - f2) < delta) //Consider them equal.
if (Math.abs(f1 - f2) > delta) // not equal. 

And that's what's happening at the end of the Math.min method - JUST in a very very precise manner by actually checking if one number is -0.0f - bitwise.

So the drawback in performance is just the more prcise result beeing calculated.

However, if you compared float values like "10", "5", and "8" - there shouldnt be a performance difference, cause the 0-check is never hit.

Answer 2

A problem with the performance of the built-in Math.min function stems from some unfortunate-in-retrospect decisions that were made when formulating the IEEE-754 Standard, especially the behavior of comparison and relational operators. The specified behavior was suitable for some purposes, but unsuitable for some other common purposes.

Most notably, if computation x would yield a positive number that is too small to represent, and computation y would yield a negative number that is too small to represent, then there is no way to directly compare the two values, they're not equivalent. Computation of 1.0/x would be interpreted as division by an infinitesimal positive number, while "1.0/y" behaves as division by an infinitesimal negative number. Thus, even though x and y are infinitesimal, and are close enough that comparison and relational operators report them as equal, both Math.min(x,y) and Math.min(y,x) should return y because it's infinitesimally smaller than x.

It strikes me as crazy that people are still designing hardware and programming languages which lack any nice means of comparing floating-point values in such a way that all pairs of values which aren't fully equivalent to each other from each other will be transitively ranked, but that has unfortunately the state of floating-point math for the last several decades. If one needs a function that will return the minimum of x and y in cases where they represent numbers with a non-zero difference, and otherwise arbitrarily return either x or y, such a function could be written more efficiently than one which has to handle the tricky cases involving positive and negative infinitesimal values.

Answer 3

Your implementation should lead to some really tight bytecode, which is easily turned into equally fast assembly language by a JIT compiler. The version using Math.min has two subroutine calls, and so may not be inlined like yours is. I think the results are to be expected.