我应该停止在 Java 中使用局部变量吗？

Question

我在 Java 和 C++ 中有这两个代码，它们应该做同样的事情。

我的直觉是 object 代码的大小（以及内容）对于R1和R2是相同的。 -O1就是这种情况（如果在没有 -O1 的情况下编译，则有 4 个字节的差异）。 Java 字节码（ R2更长）有更大的差异，这让我感到惊讶。

也许我没有看正确的东西，我的问题可能不相关，但是 Java 字节码与源代码如此“接近”是否正常，这是否意味着它总是更“高效”/“优化” " 将所有内容写成一行而不是使用局部变量？

C++

int A(int a) { return 0; }
int B(int b) { return 0; }
int C(int c) { return 0; }
int D(int d) { return 0; }

int R1() {
  return  A(B(C(3)+D(3)));
}

int R2() {
  int d = D(3);
  int c = C(3);
  int b = B(c + d);
  return A(b);
}

// Then R1() and R2() are called in the main()

Java

class MyClass {
  static int A(int a) { return 0; }
  static int B(int b) { return 0; }
  static int C(int c) { return 0; }
  static int D(int d) { return 0; }
  
  static int R1() {
    return  A(B(C(3)+D(3)));
  }
  
  static int R2() {
    int d = D(3);
    int c = C(3);
    int b = B(c + d);
    
    return A(b);
  }

  // Then R1 and R2 are called in the Main()
}

当我编译它们（ g++ -O1版本 9.4 和javac版本 11.0.17）并反汇编R1和R2时，我得到了这个：

C++ ( g++ -O1 prog.cpp )

R1:
  1251: f3 0f 1e fa             endbr64 
  1255: 53                      push   %rbx
  1256: bf 03 00 00 00          mov    $0x3,%edi
  125b: e8 9d ff ff ff          callq  11fd <_Z1Ci>
  1260: 89 c3                   mov    %eax,%ebx
  1262: bf 03 00 00 00          mov    $0x3,%edi
  1267: e8 bb ff ff ff          callq  1227 <_Z1Di>
  126c: 8d 3c 03                lea    (%rbx,%rax,1),%edi
  126f: e8 5f ff ff ff          callq  11d3 <_Z1Bi>
  1274: 89 c7                   mov    %eax,%edi
  1276: e8 2e ff ff ff          callq  11a9 <_Z1Ai>
  127b: 5b                      pop    %rbx
  127c: c3                      retq   

R2:
  <exact same as R1>

Java ( javap -c MyClass )

javap -c Appel 
static int R1();
  Code:
     0: iconst_3
     1: invokestatic  #8                  // Method C:(I)I
     4: iconst_3
     5: invokestatic  #9                  // Method D:(I)I
     8: iadd
     9: invokestatic  #10                 // Method B:(I)I
    12: invokestatic  #11                 // Method A:(I)I
    15: ireturn

static int R2();
  Code:
     0: iconst_3
     1: invokestatic  #9                  // Method D:(I)I
     4: istore_0
     5: iconst_3
     6: invokestatic  #8                  // Method C:(I)I
     9: istore_1
    10: iload_1
    11: iload_0
    12: iadd
    13: invokestatic  #10                 // Method B:(I)I
    16: istore_2
    17: iload_2
    18: invokestatic  #11                 // Method A:(I)I
    21: ireturn

Answer 1

不。您缺少的细节是优化发生的地方。

在 C-land 中，读取源代码的应用程序（例如gcc ）是进行大部分优化的应用程序（尽管越来越多的优化是由 CPU 本身在其管道和微代码翻译引擎中完成的——并不是说有作为程序员，你可以做很多事情来影响它）。 因此，正是该应用程序 ( gcc ) 具有-o （优化级别）选项，并且该应用程序可能会通过大量 CPU 周期来分析您的代码直至死亡。

在 java 领域，这不是它的工作方式。 javac在轨道上：规范准确地规定了它应该生成什么，几乎是字节 - 与 C-land 相比，C-land 规范被“mays”和“coulds”堆叠到鳃 - 编译器有很多回旋余地，特别是包括基本“字”的位宽，而 java 将所有这些锁定在规范中，无论您最终运行的 CPU 架构的位宽如何。

优化由运行时java.exe完成。 通常，它的方法比 C 更有效，因为与 C 不同，运行时获得了能够检查“实时行为”的好处，而不是 C 编译器可以做的事情（这就是为什么 C 编译器倾向于有很多“提示”系统，您可以在其中通知编译器您怀疑运行时行为可能是什么）。

所有现代 JVM 的工作方式都是低效地运行代码（javac 生成的看似低效的代码，您可以通过javap -v注意到这一点），实际上运行它的效率甚至比这低得多，因为 JVM 会添加一堆钩子来添加簿记。 例如， JVM 将跟踪调用方法的频率、运行时间，以及例如，对于每个if ，计算每个分支的执行频率。 所有这些都让它运行得更慢。

JVM 这样做，因为对于 99%（字面意思）的所有程序，大约 99%（字面意思，并不夸张）的 CPU/内存“花费”在不到 1% 的代码上，但技巧是，试图预测那是哪 1%。 通过所有这些簿记，java 将知道，然后将分析那 1% 的字节码，并使用迄今为止由于所有这些簿记而观察到的运行时行为，以得出经过微调的机器代码。 这意味着 java 开始编写分支预测的代码（确保机器代码不必为最常采用的分支路径跳转），除非它不是预测： java.exe知道哪一条是“最常采用的路径”。 与必须猜测的gcc ，可以选择由程序员在源文件中使用分支提示进行协助。

这只是java.exe可以应用机器代码优化的数千个地方之一。

这仍然意味着大约 99% 的代码运行效率非常低。 但是，考虑到这只占用不到 1% 的 CPU/内存，所以这无关紧要。

由于各种因素，Java 比 C 慢，但“优化指令”不是其中之一：

• Java 不能使用影响底层语言 model 的特定于体系结构的功能，例如曾经是协处理器的 80 位宽度变量。 Valhalla 项目正试图解决这个问题。
• 更一般地说，java 很难直接与 arch/OS-local 底层 API 交互。
• 簿记和垃圾收集器往往有“加速时间”。 它们开始时很慢，但随着时间的推移会变得更快。 比。 C 代码，几乎可以像以往一样快速运行。

那么自然地，java 对于简单的命令行一次性工具（如ls或/bin/true ）来说既不流行也不是一个好主意。 Java 在编写 web 请求响应程序时的性能非常出色。 那些运行了很长时间，热点过程确实有帮助。

Answer 2

您可能正在比较苹果和橙子。

C++ 编译器生成机器码，而 java 编译器生成字节码以在虚拟机上运行。 虚拟机要么对其进行解释，要么使用即时编译器将其转换为机器语言。

我怀疑您是否使用了 JIT 并查看了生成的机器代码。