Java方法调用性能
我有这段代码做范围最小查询 。 当t = 100000时，i和j总是在每个输入行中改变，它在Java 8u60中的执行时间约为12秒。
for (int a0 = 0; a0 < t; a0++) { String line = reader.readLine(); String[] ls = line.split(" "); int i = Integer.parseInt(ls[0]); int j = Integer.parseInt(ls[1]); int min = width[i]; for (int k = i + 1; k width[k]) { min = width[k]; } } writer.write(min + ""); writer.newLine(); } 当我提取新方法以找到最小值时，执行时间快4倍（约2.5秒）。
for (int a0 = 0; a0 < t; a0++) { String line = reader.readLine(); String[] ls = line.split(" "); int i = Integer.parseInt(ls[0]); int j = Integer.parseInt(ls[1]); int min = getMin(i, j); writer.write(min + ""); writer.newLine(); } private int getMin(int i, int j) { int min = width[i]; for (int k = i + 1; k width[k]) { min = width[k]; } } return min; }
我一直认为方法调用很慢。 但这个例子显示了相反的情况。 Java 6也certificate了这一点，但两种情况下的执行时间都要慢得多（17秒和10秒）。 有人可以对此提供一些见解吗？
TL; DR JIT编译器在第二种情况下有更多机会优化内部循环，因为堆栈内替换发生在不同的点。
我已经设法用简化的测试用例重现了这个问题。
不涉及I / O或字符串操作，只有两个具有数组访问权限的嵌套循环。
public class NestedLoop { private static final int ARRAY_SIZE = 5000; private static final int ITERATIONS = 1000000; private int[] width = new java.util.Random(0).ints(ARRAY_SIZE).toArray(); public long inline() { long sum = 0; for (int i = 0; i < ITERATIONS; i++) { int min = width[0]; for (int k = 1; k < ARRAY_SIZE; k++) { if (min > width[k]) { min = width[k]; } } sum += min; } return sum; } public long methodCall() { long sum = 0; for (int i = 0; i < ITERATIONS; i++) { int min = getMin(); sum += min; } return sum; } private int getMin() { int min = width[0]; for (int k = 1; k < ARRAY_SIZE; k++) { if (min > width[k]) { min = width[k]; } } return min; } public static void main(String[] args) { long startTime = System.nanoTime(); long sum = new NestedLoop().inline(); // or .methodCall(); long endTime = System.nanoTime(); long ms = (endTime - startTime) / 1000000; System.out.println("sum = " + sum + ", time = " + ms + " ms"); } }
inline变体确实比methodCall慢3-4倍。
我使用了以下JVM选项来确认两个基准测试都是在最高层编译的，并且在两种情况下都成功地发生了OSR（堆栈内替换） 。
-XX:-TieredCompilation -XX:CompileOnly=NestedLoop -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+TraceNMethodInstalls
‘inline’编译日志：
251 46 % NestedLoop::inline @ 21 (70 bytes) Installing osr method (4) NestedLoop.inline()J @ 21
‘methodCall’编译日志：
271 46 NestedLoop::getMin (41 bytes) Installing method (4) NestedLoop.getMin()I 274 47 % NestedLoop::getMin @ 9 (41 bytes) Installing osr method (4) NestedLoop.getMin()I @ 9 314 48 % NestedLoop::methodCall @ 4 (30 bytes) Installing osr method (4) NestedLoop.methodCall()J @ 4
这意味着JIT可以完成它的工作，但生成的代码必须不同。
让我们用-XX:+PrintAssembly分析它。
‘内联’反汇编（最热门的片段）
0x0000000002df4dd0: inc %ebp ; OopMap{r11=Derived_oop_rbx rbx=Oop off=114} ;*goto ; - NestedLoop::inline@53 (line 12) 0x0000000002df4dd2: test %eax,-0x1d64dd8(%rip) # 0x0000000001090000 ;*iload ; - NestedLoop::inline@21 (line 12) ; {poll} 0x0000000002df4dd8: cmp $0x1388,%ebp 0x0000000002df4dde: jge 0x0000000002df4dfd ;*if_icmpge ; - NestedLoop::inline@26 (line 12) 0x0000000002df4de0: test %rbx,%rbx 0x0000000002df4de3: je 0x0000000002df4e4c 0x0000000002df4de5: mov (%r11),%r10d ;*getfield width ; - NestedLoop::inline@32 (line 13) 0x0000000002df4de8: mov 0xc(%r10),%r9d ; implicit exception 0x0000000002df4dec: cmp %r9d,%ebp 0x0000000002df4def: jae 0x0000000002df4e59 0x0000000002df4df1: mov 0x10(%r10,%rbp,4),%r8d ;*iaload ; - NestedLoop::inline@37 (line 13) 0x0000000002df4df6: cmp %r8d,%r13d 0x0000000002df4df9: jg 0x0000000002df4dc6 ;*if_icmple ; - NestedLoop::inline@38 (line 13) 0x0000000002df4dfb: jmp 0x0000000002df4dd0
‘methodCall’反汇编（也是最热门的部分）
0x0000000002da2af0: add $0x8,%edx ;*iinc ; - NestedLoop::getMin@33 (line 36) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2af3: cmp $0x1381,%edx 0x0000000002da2af9: jge 0x0000000002da2b70 ;*iload_1 ; - NestedLoop::getMin@16 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2afb: mov 0x10(%r9,%rdx,4),%r11d ;*iaload ; - NestedLoop::getMin@22 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b00: cmp %r11d,%ecx 0x0000000002da2b03: jg 0x0000000002da2b6b ;*iinc ; - NestedLoop::getMin@33 (line 36) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b05: mov 0x14(%r9,%rdx,4),%r11d ;*iaload ; - NestedLoop::getMin@22 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b0a: cmp %r11d,%ecx 0x0000000002da2b0d: jg 0x0000000002da2b5c ;*iinc ; - NestedLoop::getMin@33 (line 36) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b0f: mov 0x18(%r9,%rdx,4),%r11d ;*iaload ; - NestedLoop::getMin@22 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b14: cmp %r11d,%ecx 0x0000000002da2b17: jg 0x0000000002da2b4d ;*iinc ; - NestedLoop::getMin@33 (line 36) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b19: mov 0x1c(%r9,%rdx,4),%r11d ;*iaload ; - NestedLoop::getMin@22 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b1e: cmp %r11d,%ecx 0x0000000002da2b21: jg 0x0000000002da2b66 ;*iinc ; - NestedLoop::getMin@33 (line 36) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b23: mov 0x20(%r9,%rdx,4),%r11d ;*iaload ; - NestedLoop::getMin@22 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b28: cmp %r11d,%ecx 0x0000000002da2b2b: jg 0x0000000002da2b61 ;*iinc ; - NestedLoop::getMin@33 (line 36) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b2d: mov 0x24(%r9,%rdx,4),%r11d ;*iaload ; - NestedLoop::getMin@22 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b32: cmp %r11d,%ecx 0x0000000002da2b35: jg 0x0000000002da2b52 ;*iinc ; - NestedLoop::getMin@33 (line 36) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b37: mov 0x28(%r9,%rdx,4),%r11d ;*iaload ; - NestedLoop::getMin@22 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b3c: cmp %r11d,%ecx 0x0000000002da2b3f: jg 0x0000000002da2b57 ;*iinc ; - NestedLoop::getMin@33 (line 36) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b41: mov 0x2c(%r9,%rdx,4),%r11d ;*iaload ; - NestedLoop::getMin@22 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b46: cmp %r11d,%ecx 0x0000000002da2b49: jg 0x0000000002da2ae6 ;*if_icmple ; - NestedLoop::getMin@23 (line 37) ; - NestedLoop::methodCall@11 (line 27) 0x0000000002da2b4b: jmp 0x0000000002da2af0
编译后的代码完全不同; methodCall优化得更好。
- 循环展开了8次迭代;
- 里面没有数组边界检查;
-
width字段缓存在寄存器中。
相反， inline变体
- 不循环展开;
- 每次从内存加载
width数组; - 对每次迭代执行数组边界检查。
OSR编译的方法并不总是很好地优化，因为它们必须在转换点维护解释的堆栈帧的状态。 这是同一问题的另一个例子 。
堆栈替换通常发生在后向分支上（即在循环的底部）。 inline方法有两个嵌套循环，OSR发生在内部循环中，而methodCall只有一个外部循环。 外循环中的OSR转换更有利，因为JIT编译器可以更自由地优化内循环。 这就是你的情况下究竟发生的事情。
在没有进行实际分析的情况下， getMin很可能是在将其提取到多次调用的方法时进行JIT编译。 如果您使用的是HotSpot JVM，则默认情况下会在10,000次方法执行后发生。
您始终可以使用正确的标志和JVM构建来检查应用程序使用的最终代码。 查看问题/答案如何在JVM中查看JIT编译的代码示例。
Java相对于编译为C ++的语言的一个优点是JIT（即时编译器）可以在执行代码时从字节码进行优化。 此外，Java编译器本身已准备好在构建阶段进行多次优化。 例如，这些技术允许将方法调用转换为循环内的内联代码，从而避免多态调用中重复的方法搜索开销。 使方法调用内联运行意味着方法代码的运行就像它直接写在调用方法的位置一样。 因此，没有要执行的方法，内存分配，新上下文变量的搜索开销。 基本上在你的循环中，当你在内存中分配新变量时会发生丢失处理（例如int k），当你将它传递给一个方法时，你最终会减少开销，因为变量已经被分配给了这个执行
这个问题没有提供可重复的测试用例。 所以我建立了一个专注于计算远程最小值的：
git clone git@github.com:lemire/microbenchmarks.git cd microbenchmarks mvn clean install java -cp target/microbenchmarks-0.0.1-jar-with-dependencies.jar me.lemire.microbenchmarks.rangequery.RangeMinimum
我的结果是（在配置用于测试的服务器上，Java 8）：
mlmrRangeMinimum.embeddedmin avgt 5 0.053 ± 0.009 ms/op mlmrRangeMinimum.fncmin avgt 5 0.052 ± 0.003 ms/op
因此，在我的测试用例中，有一个大循环和一个子循环，或者有一个包含函数调用的循环之间没有明显的性能差异。 请注意，基准测试会多次调用函数，以便JIT编译器可以执行其工作。
我相信java正在做一些优化/ memoization。 如果函数/方法是纯粹的，它可以缓存函数的结果。 我相信你的时间已经减少，但你的空间/记忆会增加（由于记忆），反之亦然。