在Java中使用Optional性能很慢 - pkolaczk

21-10-17 banq

该文通过与Rust对比发现:

  • 包装原始类型的Optional导致速度下降高达 8 倍,并显着提高了分配率。逃逸分析优化失败。
  • Optional在对性能极其敏感的 Java 代码中使用值可能是个坏主意。此处测试的所有 JVM 都未能优化它们。
  • 事实证明,最丑陋和最容易出错的解决方案是最快的:原始类型和魔法值。
  • 不要指望 JVM 利用了解目标 CPU 并自动利用现代指令集(如 AVX)。实际上,即使sumSimple是矢量化的教科书案例,也没有在这里进行矢量化。
  • 了解程序的实际性能配置文件也没有给 JVM 带来任何优势。
  • 幸运的是,上述建议不适用于 Rust。RustOption在大多数情况下是零成本的,即使没有内联,增加的成本也很小。您不必牺牲代码可读性或安全性来提高速度。
  • Option为我的 CPU 优化的Rust 代码返回比 Java 代码返回快30倍以上,如果以可移植的方式编译并使用默认设置和无矢量化,仍然快10 倍以上。
  • 语言及其编译器在优化强度上有很大差异。不要假设所有可以编译为机器代码的语言都是相同的。

 

2
猜你喜欢