原文網址：http://plumbr.eu/blog/how-expensive-is-a-method-call-in-java
譯文網址：http://blog.dontcareabout.us/2013/03/java-method-call.html
BBS 以 markdown 格式撰寫
______________________________________________________________________
我們都遇到過這種場景：
看著設計不良的 code，聽著寫出這 code 的人辯稱：
「你不能為了設計犧牲效能啊！」
而你就是無法說服那個人放棄那有 500 行的 method，
理由是一連串的呼叫有可能降低效能。
嗯... 在 1996 年的時候可能是真的吧？
但是後來 [JVM] 已經進化成為一個神奇的軟體了。
要發現 JVM 有多神奇的方法之一是鑽進 VM 了解更多最佳化的原理。
應用在 JVM 的技術是相當廣泛的，
不過讓我們看看其中一個技術「[inline method]」的細節。
用下面這個例子來解說最容易了：
[JVM]: http://en.wikipedia.org/wiki/Java_virtual_machine
[inline method]: http://en.wikipedia.org/wiki/Inline_function
int sum(int a, int b, int c, int d) {
return sum(sum(a, b),sum(c, d));
}
int sum(int a, int b) {
return a + b;
}
執行這段程式碼時，[JVM] 會判斷是否可以將它替換成更有效的方式，
像是 `inlined`：
int sum(int a, int b, int c, int d) {
return a + b + c + d;
}
請注意，這個最佳化是 VM 在做的，不是 compiler。
第一時間可能很難明白為甚麼會這樣？
畢竟就上頭的例子，你會疑惑：
為甚麼在 compile 階段暫緩最佳化可以產生更有效率的 bytecocde 呢？
但是考慮其他沒有那麼明顯的案例，JVM 還是實作最佳化的首選：
* [JVM] 除了有 static 的分析資料，也有執行期的資料。
在執行期，JVM 可以根據哪些 method 最常執行、
哪些載入動作是多餘的、什麼時候用 copy propagation 是安全的......
來做出更好的決策。
* [JVM] 可以得到底層架構的資訊，
像是 CPU 是幾核心、heap size、設定檔，
然後根據這些資訊來做出最佳選擇。
讓我們透過實際例子來理解這些假設。我弄了一個[小型測試程式]，
用幾種不同的方法加總 1024 個整數。
[小型測試程式]: https://bitbucket.org/Nikem/inline/src
* 用一個 array 裝 1024 個整數，然後用迴圈取得加總結果。
這是一個相對來講合理的實作方式。
實作的檔案是 [InlineSummarizer.java]。
* 用遞迴的方式作 divide and conquer：
我把原來的 1024個 element 用遞迴的方法分成兩半，
第一層遞迴得到兩個長度為 512 的 array、
第二層遞迴得到四個長度為 256 的 array...... 以此類推。
為了計算 1024 個整數的總和，我製造出 1023 個額外的 method 呼叫。
實作的檔案是 [RecursiveSummarizer.java]
* 幼稚的 divide and conquer 方式：
雖然也是對 array 作分割，不過是透過額外的實際 method 來作切半的動作。
所以我呼叫 `sum512()`、`sum256()`、`sum128()`、......、sum2()`
直到我計算完所有的 element。
跟遞迴的方法一樣，我製造出 1023 個額外的 method 呼叫。
實作的檔案是 [IterativeSummarizer.java]。
[InlineSummarizer.java]: https://bitbucket.org/Nikem/inline/src/
8e4e9eafdd2673896e8389dab7eb2bdd211ee7d5/src/eu/plumbr/demo/
inlining/InlineSummarizer.java?at=default
[RecursiveSummarizer.java]: https://bitbucket.org/Nikem/inline/src/
8e4e9eafdd2673896e8389dab7eb2bdd211ee7d5/src/eu/plumbr/demo/
inlining/RecursiveSummarizer.java?at=default
[IterativeSummarizer.java]: https://bitbucket.org/Nikem/inline/src/
8e4e9eafdd2673896e8389dab7eb2bdd211ee7d5/src/eu/plumbr/demo/
inlining/IterativeSummarizer.java?at=default
然後我用一個 [test class] 來執行這些程式。
第一個結果是沒有最佳化過的程式碼：
[test class]: https://bitbucket.org/Nikem/inline/src/
8e4e9eafdd2673896e8389dab7eb2bdd211ee7d5/src/eu/plumbr/demo/
inlining/Main.java?at=default
我們可以看到 inline 是最快的，額外產生 1023 個 method 的方法慢了約 25000ns。
但是解讀這張圖時要記得：這是 JIT 還沒有對程式碼作徹底最佳化的結果。
在 2010 年間，我用我的 MB Pro 根據各個實作方式的不同，
做了 200 到 3000 次的測試。
更實際的結果如下：我把所有加總的實作方式執行超過 1000000 次，
然後排除 JIT 沒有運作的部份，來展現它魔法：
我們可以看到即使 inline 還是表現比較好，
但是 iterative 的方式也展現了不錯的速度。
但是 recursive 就有顯著的差異，當 iterative 的方法僅有 20% 的 overhead，
`RecursiveSummarizer` 花了 inline 方法所需時間的 3.4 倍。
顯然我們必須知道：當你使用遞迴時，JVM 無法提供協助、
也不能使用 inline method call。
所以當你使用遞迴時，請注意這個限制。
撇開遞迴不談，method 的 overhead 是幾乎不存在的。
在 1023 個額外的 method 呼叫卻只有差 205ns。
不要忘了測量單位是 ns（10^-9 秒）。
因此，感謝 JIT，我們可以放心地忽略大多數 method 呼叫所產生的 overhead。
當你的同事又再用「call stack 的 pop 沒有效率」這種藉口
來掩飾他的骯髒程式碼，讓他先去上一下 [JIT 速成班]吧！
如果你想整備齊全以防堵同事的荒謬理由，請訂閱我們的 [RSS] 或 [Twitter]，
我們很高興提供你更多案例研究。
[JIT 速成班]: http://plumbr.eu/blog/do-you-get-just-in-time-compilation
[RSS]: http://plumbr.eu/blog/feed
[Twitter]: https://twitter.com/JavaPlumbr