該文通過與Rust對(duì)比發(fā)現(xiàn)：
- 包裝原始類型的Optional導(dǎo)致速度下降高達(dá) 8 倍，并顯著提高了分配率。逃逸分析優(yōu)化失敗。
- Optional在對(duì)性能極其敏感的 JAVA 代碼中使用值可能是個(gè)壞主意。此處測(cè)試的所有 JVM 都未能優(yōu)化它們。
- 事實(shí)證明，最丑陋和最容易出錯(cuò)的解決方案是最快的：原始類型和魔法值。
- 不要指望 JVM 利用了解目標(biāo) CPU 并自動(dòng)利用現(xiàn)代指令集（如 AVX）。實(shí)際上，即使sumSimple是矢量化的教科書案例，也沒有在這里進(jìn)行矢量化。
- 了解程序的實(shí)際性能配置文件也沒有給 JVM 帶來任何優(yōu)勢(shì)。
- 幸運(yùn)的是，上述建議不適用于 Rust。RustOption在大多數(shù)情況下是零成本的，即使沒有內(nèi)聯(lián)，增加的成本也很小。您不必犧牲代碼可讀性或安全性來提高速度。
- Option為我的 CPU 優(yōu)化的Rust 代碼返回比 Java 代碼返回快30倍以上，如果以可移植的方式編譯并使用默認(rèn)設(shè)置和無矢量化，仍然快10 倍以上。
- 語言及其編譯器在優(yōu)化強(qiáng)度上有很大差異。不要假設(shè)所有可以編譯為機(jī)器代碼的語言都是相同的。
