我正在用三維視其刷新30次（或至少試圖渲染快）的應用程序。不幸的是，代碼是夠複雜了，簡單地將其轉換爲測試性能的影響將需要相當長一段時間，但在兩種情況我會比較如下：Java的效率：對象分配和方法調用與聯方法調用
ObjectToRender p = objectsToRender.get(i);
p.render();
，而不是：
objectsToRender.get(i).render();
我敢肯定，這聽起來像微優化的一個嚴重的情況，但如上所述，該代碼不斷被調用，具有零度之外的因素影響它的性能（磁盤I/O，網絡等）。
代碼的objectsToRender.get(i)部分可以通過使用迭代器遍歷所有對象渲染優化：
iterator.next().render();
，或者如果對象的列表是穩定的，將其轉換爲ObjectToRender[]一次，直接索引：
objectsToRender[i].render();
-1您沒有提供任何證明這些更好;你甚至不能，因爲你不知道他運行的是什麼環境，JDK版本等等。 試圖只給一個問題的常識答案並不真正幫助這個傢伙。 – 2010-01-19 18:17:19
@凱文，正如你已經說過的那樣;給出一個證明不是這樣的問題的答案的目標，試圖提供建議是。 OP要看看他遵循的是什麼建議。這就是說，對集合中的所有對象進行循環時，對於包含'.get（int）'的集合類來說，優化全局算法是非常好的選擇。 – rsp 2010-01-19 20:00:54
我欣賞任何和所有建議，謝謝。從邏輯層面思考，僅使用toArray（）可能會妨礙性能，因爲它需要在每個視口刷新時發生。 – sbook 2010-01-19 23:02:28
我希望這兩段代碼以JIT編譯成一模一樣的機器代碼，假設你不使用「P」這個片段之後的任意位置。
編譯一個示例並使用'javap -c'來獲取我的投票。 :) – 2010-01-19 17:36:39
@ mmyers，即使兩個不能編譯成相同的字節碼，他的觀點仍然有效。 – 2010-01-19 18:07:18
他說什麼。最近我做的一些測試表明，Java CLR相對於CLR來說是非常積極的。你真的不需要擔心像這樣的明顯的微優化。 – 2010-01-19 22:02:35
您建議的更改不應該Mattern的，雖然你可能從基於索引列表訪問移動得到改善（這是我假設你正在使用「獲得（I）」），以數組訪問。
大多數現代編譯器都足夠聰明，可以生成非常優化的字節碼。我懷疑上述兩個電話應該有什麼區別。事實上，他們會生成相同的字節碼。
應該沒有什麼區別，但我看到了性能差異，我認爲我不應該看到它。
正如你所說，雖然，這似乎是一個微型的優化，你可能會通過尋找更大的優化，例如代碼重構，甚至將不同的圖形工具，獲取更多轟隆的。
如果你關心的幀速率，您應顯示或記錄您的幀速率和對一個給定的預編程測試一些標準化的目標。一旦你做完了這些，測試一些小的變化應該會給你關於各種調整的即時反饋。
不要使「性能增強」無法測量它們。這就像你迷路了一樣，並且建議將你的駕駛速度提高到40英里/小時以上，因爲你沒有時間停下來詢問路線。
與丟失和建議增加駕駛速度的優秀比較..我必須記住那一個！ Framerate實時顯示並寫入日誌文件，所以我很清楚在做出更改時哪些更改會有所幫助或受到傷害。這個變化太大了，可能會變成一場瘋狂的追逐.. – sbook 2010-01-19 22:59:34
這聽起來像是一個微型優化的嚴重情況。 – 2010-01-19 18:24:23
這絕對是一個嚴重的情況，但是以每秒30次的速度遍歷數千個「objectsToRender」是這樣的事情可能開始有所作爲的數量級。 – sbook 2010-01-19 22:53:37