我分析了我的代码,发现我的类实现Comparable<T>
了 8 倍以上的 cpu 时间
compareTo(Object)
比在
compareTo(T)
我认为减速是因为此方法的虚拟表查找。
有没有办法强制静态调用函数?(就像在非虚拟 C++ 方法中一样)
我仍然想使用Comparable<T>
接口,因为我使用TreeSet
了这个对象并且我不想重写这个代码。
编辑:不,我没有实现compareTo(Object) - 这是由探查器自动生成和报告的
我分析了我的代码,发现我的类实现Comparable<T>
了 8 倍以上的 cpu 时间
compareTo(Object)
比在
compareTo(T)
我认为减速是因为此方法的虚拟表查找。
有没有办法强制静态调用函数?(就像在非虚拟 C++ 方法中一样)
我仍然想使用Comparable<T>
接口,因为我使用TreeSet
了这个对象并且我不想重写这个代码。
编辑:不,我没有实现compareTo(Object) - 这是由探查器自动生成和报告的
您看到的原因compareTo(Object)
是因为Type Erasure。它只是意味着在运行时不再需要类型信息来比较值。您减速的最有可能的原因是 1)非常非常大的 TreeSet 有很多元素 2) - 更有可能 - 您的 compareTo 方法做了一些昂贵的事情。因为它被非常频繁地调用(通常 n*ln(n) 次),它应该被有效地实现
不,在这种情况下您不能强制进行静态调用。
指令可以“非虚拟地”调用实例方法invokespecial
。当目标在编译时已知时使用此指令,例如构造函数或私有方法。在其他情况下——即使目标方法是final
——使用invokevirtual
orinvokeinterface
指令。
由于 java在运行时不保留泛型类型,因此理想情况下它们的行为应该相同。可能还有其他原因导致问题。
我认为减速是因为此方法的虚拟表查找。
您不必猜测这是否属实。只需暂停几次,您就会在表演中抓住它。完整显示调用堆栈,包括对库例程的调用。
我的猜测(可能是错误的)是它正在经历 9 码的 OLE 风格调用 hoo-haw。