2

我想對何時(忽略可用內存空間)有一個明確的理解,它存儲比較的結果而不是重新計算它是有意義的。證明存儲所帶來的時間成本的轉折點是什麼?它是2,3或4比較?更多?什麼時候存儲比較結果與重新計算速度比較有何意義?

例如,在這種特殊情況下,哪個選項(通常)在速度方面表現更好?

選項1:

int result = id.compareTo(node.id); 

return result > 0 ? 1 : result < 0 ? -1 : 0; 

選項2:

return id.compareTo(node.id) > 0 ? 1 : id.compareTo(node.id) < 0 ? -1 : 0; 

我試着來分析這兩個選項自己爲了回答我的問題,但是我沒有這個很多經驗這樣的性能測試,因此,寧願從具有更多經驗或更好地理解所涉及的理論元素的人那裏得到更明確的答案。

我知道這不是什麼大不了的事情,而且大多數情況下差異可以忽略不計。然而,我是一個完美主義者,我真的想解決這個特殊問題,以便我可以繼續我的生活,哈哈。

此外,我認爲這個答案很可能會對我在將來可能遇到的類似情況有所啓​​發,其中差異可能非常顯着(例如比較或內存分配的成本無法達到被招致或者足夠複雜,導致有關性能的真正問題)。

答案應該與Java編程相關,而不是其他語言。

我知道我已經提到過幾次了,但請僅將注意力集中在SPEED DIFFERENCE上!我很清楚在編寫代碼時可以並且應該考慮許多其他因素,但是在這裏我只想要一個更快的參數。

+0

首先考慮可讀性,然後是性能! – ewernli 2013-03-19 12:29:01

+0

@ewernli 的確如此,但我所尋找的答案實際上只是面向一個優先事項:表現。我明白,在實際應用中,我當然會考慮其他(可以說更重要的)優先事項。但是,謝謝你的提醒! – sweetname 2013-03-19 12:54:12

+0

你仍然可以嘗試測量執行時間,調用測試方法一百萬次,使用nanoTime()進行測量,並通過兩種方法的一百萬次調用來溫暖他的虛擬機。看看方法沒有被優化掉:總結每個方法調用的結果,並最終打印出結果。 – AlexWien 2013-03-19 13:21:43

回答

2

經驗告訴我,選項1應該更快,因爲您只是對比較方法進行一次調用並存儲結果以供重用。支持這種觀點的事實是,局部變量存在於堆棧上,並且進行方法調用涉及堆棧的更多工作,而不僅僅是將值推入堆棧。然而,分析是比較兩種實現的最好和最安全的方法。

實現的第一件事是,Java編譯器和JVM希望如何把工作最有效的(只要一定的規則得到遵守)一起做可以優化你的代碼。機會是沒有差異的表現,也有可能是實際執行的不是你認爲的那樣。 然而,一個非常重要的區別是在調試時:如果您在store-in-variable版本的return語句中放置了一個斷點,則可以看到該調用返回的內容,否則在調試器中看不到該斷點。更方便的是,當你看似無用地將要從方法返回的值存儲在一個變量中時,然後返回它,這樣您可以在調試時看到方法返回的內容,否則無法看到它。

+0

你能解釋一下「strie-in-variable version」是什麼意思嗎?我很抱歉,如果這是一個愚蠢的問題,但我無法提出任何可以通過快速谷歌搜索定義該術語的內容。 另外,你會願意探討爲什麼在你的答案是這樣的情況? – sweetname 2013-03-19 12:20:49

+0

這是一個錯字 - 我已經編輯了我的答案來糾正它(我正在看電視的同時在iPhone上打字):) – Bohemian 2013-03-19 12:26:28

+0

謝謝!我會贊成,但我還沒有足夠的代表... – sweetname 2013-03-19 12:52:22

0

選項1一個總是首選之一,因爲這裏的現實世界scenarion

----->確定用於

1)線程exceution在id.compareTo(node.id)> 0?1,在這個過程中的一些其他線程

改變的node.id權id.compareTo(node.id) > 0 ? 1之後纔去

id.compareTo(node.id) < 0 ? -1 : 0此檢查,結果不相同的價值?

性能明智的選項1有更多的性能時,有一點功能exisist在檢查。

+0

你能否編輯你的語法和拼寫答案,以便使它更清楚一點?我想我知道你要去哪裏,但是再一次......我不確定我是否確實遇到了上述困難。 – sweetname 2013-03-19 12:50:57

1

選項1不能慢於2,如果編譯器優化,那麼兩者可能相等,但仍然1)更具可讀性,更好,更好的可測試性。

所以沒有選項2的參數)。

如果你想雖然我想到的是,編譯器是太聰明瞭,最後的關鍵字使得在這種情況下沒有什麼區別,你可以更改爲final int result = .... ,並最終使代碼有點不太可讀。

+0

有趣的是,我沒有考慮使用final關鍵字。你能否進一步解釋什麼是預期的優化(儘管也許是不必要的)? – sweetname 2013-03-19 13:48:12

+0

當你查看java的文檔時,你會發現最終的局部變量是一個只能被賦值一次的變量,所以它不能在以後改變。 java的意圖是爲編譯器提供更好的優化提示。 (但是,根據編譯器的不同,它可能會分析出該變量不再被修改,並將其視爲如果已將其明確定義爲final) – AlexWien 2013-03-19 14:45:40

0

什麼時候存儲比較結果與重新計算速度比較有什麼意義?

大多數情況下,像選項#1和選項#2這樣的微觀優化沒有任何顯着的區別。事實上,它只會讓一個顯著的性能差異,如果:

  • 比較昂貴,
  • 執行比較大量的時間和
  • 性能問題。

事實上,有機會,你有alrady花更多的時間和金錢思考這個比將被保存在應用程序的整個使用壽命。

您應該專注於使您的代碼可讀,而不是專注於性能。想想下一個必須閱讀和修改代碼的人,並且讓他/她不太可能誤解它。

在這種情況下,第一個選項比第二個選項更具可讀性。這就是爲什麼你應該使用它,而不是性能的原因。 (儘管如此,第一個版本可能會更快。)

+0

最後一個句子不完整 – AlexWien 2013-03-19 13:18:19

+0

對不起,但問題很明顯要求速度比較,沒有任何與其他問題有關的建議或信息。我只是想要一個基於邏輯的理論答案,或者是一個基於數學的實驗答案,而不是關於編寫代碼時考慮其他因素的重要性的講座(我已經很清楚的事情)。再一次,我讚賞這種擔憂,但在這個特殊的背景下,你的回答是不恰當的。 – sweetname 2013-03-19 13:46:05

+0

@sweetname:沒有邏輯或數學答案。你可以得到最接近的結果是嘗試它,或者研究抖動產生的彙編語言,或者在像kachegrind這樣的循環級解釋器下運行它。我所做的是在一個現實的程序中運行它(不管語言如何),並且如果有一些隨機暫停在那裏捕獲它,請修復它。 – 2013-03-19 15:17:27