Scala optimization witth specialized types: sum with longs

I have the following simple code

val longs: Vector[Long] = (1L to 1000000L).toVector

and the supposedly equivalent Java

def jLongs: java.util.stream.LongStream = java.util.stream.LongStream
    .iterate(1L, (i: Long) => i <= 1000000L, (i: Long) => i + 1L)

When I run a benchmark with the following code

@State(Scope.Benchmark)
@BenchmarkMode(Array(Mode.AverageTime))
@OutputTimeUnit(TimeUnit.MILLISECONDS)
class BoxingScala {
  val longs: Vector[Long] = (1L to 1000000L).toVector
  def jLongs: java.util.stream.LongStream = java.util.stream.LongStream
    .iterate(1L, (i: Long) => i <= 1000000L, (i: Long) => i + 1L)

  @Benchmark def a: Long = longs.sum

  @Benchmark def b: java.lang.Long = jLongs.sum()
}

I get that the Java code is roughly 400% faster. When I try to understand why, I find this bytecode:

  // access flags 0x1
  public a()J
  @Lorg/openjdk/jmh/annotations/Benchmark;()
   L0
    LINENUMBER <benchmark a> L0
    ALOAD 0
    INVOKEVIRTUAL gurghet/BoxingScala.longs ()Lscala/collection/immutable/Vector;
    GETSTATIC scala/math/Numeric$LongIsIntegral$.MODULE$ : Lscala/math/Numeric$LongIsIntegral$;
    INVOKEVIRTUAL scala/collection/immutable/Vector.sum (Lscala/math/Numeric;)Ljava/lang/Object;
    INVOKESTATIC scala/runtime/BoxesRunTime.unboxToLong (Ljava/lang/Object;)J
    LRETURN
   L1
    LOCALVARIABLE this Lgurghet/BoxingScala; L0 L1 0
    MAXSTACK = 2
    MAXLOCALS = 1

  // access flags 0x1
  public b()Ljava/lang/Long;
  @Lorg/openjdk/jmh/annotations/Benchmark;()
   L0
    LINENUMBER <benchmark b> L0
    GETSTATIC scala/Predef$.MODULE$ : Lscala/Predef$;
    ALOAD 0
    INVOKEVIRTUAL gurghet/BoxingScala.jLongs ()Ljava/util/stream/LongStream;
    INVOKEINTERFACE java/util/stream/LongStream.sum ()J (itf)
    INVOKEVIRTUAL scala/Predef$.long2Long (J)Ljava/lang/Long;
    ARETURN
   L1
    LOCALVARIABLE this Lgurghet/BoxingScala; L0 L1 0
    MAXSTACK = 3
    MAXLOCALS = 1

where longs is initialized by

 L1
    LINENUMBER <init> L1
    ALOAD 0
    NEW scala/runtime/RichLong
    DUP
    GETSTATIC scala/Predef$.MODULE$ : Lscala/Predef$;
    LCONST_1
    INVOKEVIRTUAL scala/Predef$.longWrapper (J)J
    INVOKESPECIAL scala/runtime/RichLong.<init> (J)V
    LDC 1000000
    INVOKESTATIC scala/runtime/BoxesRunTime.boxToLong (J)Ljava/lang/Long;
    INVOKEVIRTUAL scala/runtime/RichLong.to (Ljava/lang/Object;)Lscala/collection/immutable/NumericRange$Inclusive;
    INVOKEVIRTUAL scala/collection/immutable/NumericRange$Inclusive.toVector ()Lscala/collection/immutable/Vector;
    PUTFIELD gurghet/BoxingScala.longs : Lscala/collection/immutable/Vector;

So it seems to me that the scala version is forced to load a million objects.

Is this the reason why it's so slow? How can I tell to specialize for longs?

Also, it is interesting and counter intuitive the fact that, while the java code returns an object, in scala a primitive long is returned (cf. ARETURN vs. LRETURN).

<!-- language-all: scala -->

Looking at the bytecode is futile. The difference is in what a Stream is. A LongStream produces elements on demand. It's not a data structure; it's a control structure—a latent loop over some other data source. Your Java boils down to

var sum: Long = 0
for(i <- 1L to 1000000L) sum += i;

A Vector is an actual data structure, which actually has to store 100000 longs, making your Scala version essentially

val oops = new Array[java.lang.Long](1000000) // boxed!
for(i <- 0 until 1000000) oops(i) = i + 1
var sum: Long = 0
for(i <- 0 until 1000000) sum += oops(i)

There is absolutely no equivalence between these. Also note that 1L to 1000000L is a NumericRange[Long], which already is a Scala collection, and (1 to 1000000L).sum is much faster than either of these, since it uses a simple arithmetic formula to compute the result. The closest thing to a LongStream is actually a SeqView[Long], which you can get as (1L to 1000000).view. If you call sum on that, I believe the collections library is not smart enough to simplify that down to a sum call on the NumericRange, and will instead iterate it like in the Java version, making a closer comparison. It won't be specialized to Long, though, so it will still have the boxing penalty.