Java表達式優化

我有代碼，所有的地方（大概20-30實例）做到這一點：Java表達式優化

<widget>.setVisible((condition == VIEW) || (condition == EDIT));

按道理我也明白，Java編譯器應該而且可能會優化這個計算起來前並簡單地使用計算的布爾值。

我的問題是有什麼辦法來真正證實這種情況？

澄清

condition是private類成員沒有辦法改變它過去的建設。

來源

2012-03-23 Karlson

我不會依賴編譯器來優化它。雖然這是可能的，但它非常複雜，僅在某些情況下有用：如果'condition'是一種方法局部變量幾乎可能並且可能完成。如果不是，那取決於「條件」的可變性（通過setVisible sideeffects，其他線程等）。 – dronus 2012-03-23 15:26:25

@卡爾森：我認爲你不知道什麼樣的超重炮會在（可見）部件改變其狀態並因此需要變得可見或隱藏時在罩下進行。如果你認爲你需要優化這個檢查，因爲你可能最終會經常打電話給你，你會遇到很大的麻煩，因爲這絕對不會降低你的應用的速度...... – TacticalCoder 2012-03-23 15:29:05

另外你的例子似乎相當可疑，術語小部件和'setVisible'讓我假設有一個代價高昂的GUI操作或類似的東西，這會使優化的布爾表達式的效果不可見，這是由於這種表達式對常規GUI框架代碼的執行限制的巨大差異。 – dronus 2012-03-23 15:30:48

拆分類文件爲javap，例如，

javap -c com.example.ClassName

查看字節碼的來源。但是，爲什麼不通過提取一個臨時布爾變量來保證優化呢？

來源

2012-03-23 15:28:51 paislee

反彙編字節碼。

也就是說，這些類型的優化可能在運行時完成，可能取決於condition的聲明，取決於條件所在的位置等等。追蹤像這樣的優化在所有最簡單的用例中都不是微不足道的。

來源

2012-03-23 15:24:46

有沒有什麼辦法可以真正驗證這種情況？

你可以嘗試通過看字節碼拆卸，以驗證這一點，那麼在通過熱點產生的機器代碼等

不過，我認爲這個策略是充滿了困難。這也是脆弱的，因爲結果取決於編譯器/ JVM和對condition的確切性質（是本地？類成員？final？volatile？）

如果你關心的優化性能的原因[1 ]，我的建議是通過分解通用表達式來手動執行它。

[1]我假設你已經對代碼進行了剖析，並且知道這是一個瓶頸。

來源

2012-03-23 15:40:02 NPE

是的，它不是其中之一。 – Karlson 2012-03-23 15:56:39

Java表達式優化

回答

相關問題