CompareToBuilder的這種用法是否被認爲效率低下？

Question

在同行評審期間，開發人員似乎對實施compareToBuilder解決方案感到震驚，因爲我選擇按3個屬性進行排序。他的印象是，我班的compareTo方法會爲每次比較創建過多的比較器，並且該應用程序會對性能產生巨大影響。他建議我使用BeanComparator & ComparatorUtils來鏈接比較器。

這是我的課：

public class EmployeeComparator implements Comparator<Employee> { 

@Override 
public int compare(Employee o1, Employee o2) { 
    return new CompareToBuilder() 
      .append(o1.getJobTitle(), o2.getJobTitle()) 
      .append(o1.getAge(), o2.getAge()) 
      .append(o1.getSalary(), o2.getSalary()).toComparison(); 
} 

這是我實現：

Collections.sort(outputRecordList, Comparator.nullsLast(new EmployeeComparator())); 

不過，我真的不知道這是不是真的。我無法找到任何可能表明這會對使用鏈式比較器造成重大性能影響的內容。我通過Apache文檔挖掘出來，看起來這是該類的一個標準實現（https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/builder/CompareToBuilder.html）。我唯一擔心的是通過添加「Comparator.nullsLast」，我創建了一個怪物。

我發現這個網站在這裏CompareToBulder實現：

http://www.codejava.net/java-core/collections/sorting-a-list-by-multiple-attributes-example

任何幫助或者解釋爲什麼這是不好的做法或解釋究竟CompareToBuilder做將不勝感激。

Answer 1

代碼評論：首頁微優優化。基於這些有限的信息，我不明白他怎麼能預測它會「對業績造成巨大打擊」。

您的代碼是否有非功能性要求比X快？如果沒有，請隨時忽略他的評論。你的代碼是可讀的，可重用的和可維護的。如果它進行1或2次閃電比較超過絕對必要，這並不重要。除非您每次以百萬計的方式比較這些數據，否則從字面上看，沒有實際的區別。花時間考慮它只是浪費時間。

---

正確的方法來優化任何代碼：

1. 措施是否有合法的問題
2. 決定什麼樣的可接受的性能水平
3. 優化的代碼，並重新測量直到它至少可以接受爲止

根據需要重複

Answer 2

CompareToBuilder對於您的使用看起來相當高效（從查看其源代碼）。與硬編碼比較比較時，它涉及一個額外的實例創建（僅包含一個int字段）和append（）調用（可能由HotSpot編譯器內聯）。即使第一次比較已經確定了結果，它也必須通過所有尾部比較。

實現它，然後執行系統分析。如果EmployeeComparator需要花費大量時間，請再想一想：但我認爲更快的compareTo（）實現對此沒有多大幫助。