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

該文通過與Rust對比發現：

• 包裝原始型別的Optional導致速度下降高達 8 倍，並顯著提高了分配率。逃逸分析優化失敗。
• Optional在對效能極其敏感的 Java 程式碼中使用值可能是個壞主意。此處測試的所有 JVM 都未能優化它們。
• 事實證明，最醜陋和最容易出錯的解決方案是最快的：原始型別和魔法值。
• 不要指望 JVM 利用瞭解目標 CPU 並自動利用現代指令集（如 AVX）。實際上，即使sumSimple是向量化的教科書案例，也沒有在這裡進行向量化。
• 瞭解程式的實際效能配置檔案也沒有給 JVM 帶來任何優勢。
• 幸運的是，上述建議不適用於 Rust。RustOption在大多數情況下是零成本的，即使沒有內聯，增加的成本也很小。您不必犧牲程式碼可讀性或安全性來提高速度。
• Option為我的 CPU 優化的Rust 程式碼返回比 Java 程式碼返回快30倍以上，如果以可移植的方式編譯並使用預設設定和無向量化，仍然快10 倍以上。
• 語言及其編譯器在優化強度上有很大差異。不要假設所有可以編譯為機器程式碼的語言都是相同的。