Comparing integers has unexpected overhead

[informarte]

I am migrating a project from Scala 2.12.8 to 2.13.0. While investigating a performance degradation, I came across an issue that's not new to Scala 2.13: Comparing integers like in the following piece of code

    private final class EventPoint(val x: Int, val bbox: Rect2d, val isBBoxStart: Boolean)
    private object EventPointOrdering extends Ordering[EventPoint] {
        override def compare(p1: EventPoint, p2: EventPoint) = p1.x.compare(p2.x)
    }

has unexpected overhead. I use this ordering to sort an EventPoint array and found that the use of EventPointOrdering accounts for 10% of the runtime:

(I used VisualVM for profiling and the program was compiled with full optimization and inlining.)

This call stack is terrifying, isn't it? I think that RIchInt (and all the other boxes for primitive types) should override compare instead of relying on OrderedProxy.

I solved my performance issue by using java.lang.Integer.compare directly.

[NthPortal]

This is an unfortunate effect of some subtle boxing that happens when you write p1.x.compare(p2.x). That expression desugars to scala.Predef.intWrapper(p1.x).compare(p2.x); intWrapper creates a scala.runtime.RichInt wrapping p1.x. Some of RichInt's methods (e.g. until) can be invoked without actually creating a wrapping object; however, because compare is inherited from ScalaNumberProxy, which is a trait, an instance of it needs to be instantiated to invoke compare on. On top of this, ScalaNumberProxy is not specialized, so its compare method is actually compare(java.lang.Object):Int which means that p2.x gets boxed as well. Then the two Ints eventually get unboxed once it calls java.lang.Integer.compare (which is how Ordering[Int] is actually implemented). Not to mention that there's quite a bit of bridge forwarding, though I doubt that's the major factor in the performance cost.

Note: even without ScalaNumberProxy, both values will get boxed because scala.math.Ordering is not specialized, so its actual method signature in bytecode is compare(java.lang.Object,java.lang.Object):Int, so each Rich<Type> wrapper would need to implement each individual method directly without touching Ordering[<Type>].

I personally think inlining all the method implementations would be nice, but I'm not sure whether others consider the maintenance cost to be worth it.

[martijnhoekstra]

:sadtrombone:

Would making the compare methods final in these traits help the compiler and/or the JIT with inlining?

Also, is there a reason that ordering is not specialized? Should it be?

[hrhino]

What needs to happen here, IIUC, is that universal traits need to get the extmethods treatment (pulled into a static object) so that we can rewrite calls as we do for methods on value classes.

There's some subtlety and a ticket already discussing it; let's see if I can find it before Seth Lukas.

[lrytz]

#9731 (comment) ...

[sjrd]

The amount of abstraction involved in implementing some of the methods in RichXyz classes is absolutely insane, given that those methods appear as members of primitive types by default. There should be no reason to go through universal traits and Orderings whatsoever. It would be much better for everyone if all the RichXyz classes were self-contained, and implemented all their methods using basic operators and methods from java.lang.

WiP at scala/scala@2.13.x...sjrd:efficient-rich-primitives, showing how to do it for Boolean, Byte, Int and Double. Feel free to pick it up and finish the other primitive types, then you can delete src/library/runtime/ScalaNumberProxy.scala altogether.

[jxnu-liguobin]

pick..