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（）实现对此没有多大帮助。