java 內聯調用深度

總覽

動態編譯的好處之一是它能夠支持在虛擬方法代碼上的廣泛方法內聯。

內聯代碼可提高性能時，代碼仍必須檢查類型（以防由于優化而更改了類型）或在多個可能的實現之間進行選擇。

這導致了問題。 通過接口調用的方法的多個實現如何影響性能。

標桿管理

此基準測試了作為列表元素調用的簡單方法。 它比較列表中不同類的數量以查看其性能，但還改變了展開循環的數量，從而減少了可能的類數量。 例如，對于一個12種不同類的列表，以重復模式，在不展開的情況下，方法調用可能是12種類中的任何一種，但是當循環展開為2種程度時，每個調用只有6種可能的類（12 / 2）。 展開為三個級別時，每個調用有12個（4/3）個可能的類，對于展開為六個級別的循環，只有兩個可能的類。 注意：每行代碼可能的類都不相同。

這些是2.5 GHz i5上的結果。 時間以納秒為單位。 軸標題是指從給定代碼行使用或調用的不同類的數量。

	1二手	2二手	3二手	4二手	6二手	8二手	12已使用
每個呼叫站點1個	48.4	46.6	46.9	43.7	48.7	54.9
每個呼叫站點2個		115.8		80.5	92.8	87	112
每個呼叫站點3個			285		283		271
每個呼叫站點4個				669		281	275
每個呼叫站點6個					562		275
每個呼叫站點8個						498
每個呼叫站點12個							530

看起來，加載的類的數量，甚至列表中的類的數量，都不如從給定代碼段調用的可能的類的數量重要。 看起來同一循環中的不同代碼段可以獨立進行優化。

您會看到，如果給定調用只能創建一個可能的類，則程序中使用的類數無關緊要。

另一個含義是，如果要通過一個公共接口比較兩個選擇，則必須小心如何運行測試，這樣就不會因為只使用一種類型的事實而偏愛第一次運行。 為了解決這個問題，我建議； 多次運行所有測試，總共至少2秒鐘。 這樣可以減少與您執行測試的順序相關的bais。

參考：來自Vanilla Java博客的JCG合作伙伴 Peter Lawrey 在Java中內聯虛擬方法調用的性能 。

翻譯自: https://www.javacodegeeks.com/2012/12/performance-of-inlined-virtual-method-invocations-in-java.html

java 內聯調用深度

總結

以上是生活随笔為你收集整理的java 内联调用深度_Java中内联虚拟方法调用的性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。