java - `scale` 中的 `BigDecimal#divide()` 越高，速度越快？

Question

我提出了一个问题，最初是一个问答式的问题。

原问题:

scale 中的 BigDecimal#divide() 越高，对性能的影响有多大？

所以，我创建了这个 SSCCE:

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.concurrent.TimeUnit;

public class Test {

    public static void main(String args[]) {
        int[] scales = new int[] {1, 10, 50, 100, 500, 1000, 5000, 100000, 1000000};
        for(Integer scale : scales) {
            long start = System.nanoTime();
            BigDecimal.ONE.divide(BigDecimal.valueOf(7), scale, RoundingMode.HALF_UP);
            long end = System.nanoTime();
            long elapsed = end - start;
            String elapsed_str = String.format("%d mins, %d secs, %d millis, %d nanos", 
                TimeUnit.NANOSECONDS.toMinutes(elapsed),
                TimeUnit.NANOSECONDS.toSeconds(elapsed) - TimeUnit.MINUTES.toSeconds(TimeUnit.NANOSECONDS.toMinutes(elapsed)),
                TimeUnit.NANOSECONDS.toMillis(elapsed) - TimeUnit.SECONDS.toMillis(TimeUnit.NANOSECONDS.toSeconds(elapsed)),
                elapsed - TimeUnit.MILLISECONDS.toNanos(TimeUnit.NANOSECONDS.toMillis(elapsed))
            );
            System.out.println("Time for scale = " + scale + ": " + elapsed_str);
        }
    }
}

输出如下:

Time for scale = 1: 0 mins, 0 secs, 2 millis, 883903 nanos
Time for scale = 10: 0 mins, 0 secs, 0 millis, 13995 nanos
Time for scale = 50: 0 mins, 0 secs, 1 millis, 138727 nanos
Time for scale = 100: 0 mins, 0 secs, 0 millis, 645636 nanos
Time for scale = 500: 0 mins, 0 secs, 1 millis, 250220 nanos
Time for scale = 1000: 0 mins, 0 secs, 4 millis, 38957 nanos
Time for scale = 5000: 0 mins, 0 secs, 15 millis, 66549 nanos
Time for scale = 100000: 0 mins, 0 secs, 500 millis, 873987 nanos
Time for scale = 1000000: 0 mins, 50 secs, 183 millis, 686684 nanos

随着数量级的增加，性能受到指数级影响。但让我摸不着头脑的是这些行:

Time for scale = 1: 0 mins, 0 secs, 2 millis, 883903 nanos
Time for scale = 10: 0 mins, 0 secs, 0 millis, 13995 nanos
Time for scale = 50: 0 mins, 0 secs, 1 millis, 138727 nanos
Time for scale = 100: 0 mins, 0 secs, 0 millis, 645636 nanos
Time for scale = 500: 0 mins, 0 secs, 1 millis, 250220 nano

看来 10 的规模对于 BigDecimal#divide() 来说是最佳的？ 100 的规模比 50 更快？我认为这可能只是一个异常，所以我再次运行了它(这次，省略了最高的两个刻度，因为我不想等待 50 秒:))，这就是结果:

Time for scale = 1: 0 mins, 0 secs, 3 millis, 440903 nanos
Time for scale = 10: 0 mins, 0 secs, 0 millis, 10263 nanos
Time for scale = 50: 0 mins, 0 secs, 0 millis, 833169 nanos
Time for scale = 100: 0 mins, 0 secs, 0 millis, 487492 nanos
Time for scale = 500: 0 mins, 0 secs, 0 millis, 802846 nanos
Time for scale = 1000: 0 mins, 0 secs, 2 millis, 475715 nanos
Time for scale = 5000: 0 mins, 0 secs, 16 millis, 646117 nanos

同样， 10 比 1 快得多，并且 100 又比 50 快。

我一次又一次地尝试，100 总是比 50 更快。并且 1 的规模总是比小于 1000 的所有内容慢。

谁能解释一下吗？

Answer 1

Java 代码是动态优化的，但是第一次运行它时，必须加载它。为了避免在运行时重新编译代码而导致困惑的结果，我建议

• 首先进行最长的运行，而不是最后。
• 运行测试至少 2 秒。
• 忽略至少 3 到 5 次运行中的第一次运行(在本例中只有一次)

我会保持比例简单，以便您可以比较所有结果。在你的例子中，我会每一项至少执行 1000 次，并以微秒为单位打印平均值。