在Java中使用Optional的开销很大 - pkolaczk

该文通过与Rust对比发现：

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