Reverted: use optimised ByteString.asInputStream

[pjfanning]

• ByteString.asInputStream is only in Pekko 1.1 - so if you use this code with Pekko 1.0, the MethodHandle will not work and the code falls back to existing ByteArrayInputStream

[pjfanning]

I benchmarked this using https://github.com/pjfanning/pekko-test/blob/main/bench/src/main/scala/org/example/pekko/ByteStringBench.scala

The new code (in this PR) was faster for byte strings that are made up of multiple byte strings but slower for simple byte strings.

[info] Benchmark                                 Mode  Cnt       Score        Error  Units
[info] ByteStringBench.newGetInputStream        thrpt    3     752.065 ±    787.928  ops/s
[info] ByteStringBench.newGetInputStreamSimple  thrpt    3  447966.746 ± 273762.965  ops/s
[info] ByteStringBench.oldGetInputStream        thrpt    3     535.979 ±   1080.417  ops/s
[info] ByteStringBench.oldGetInputStreamSimple  thrpt    3  486935.775 ± 222571.828  ops/s

While the speedup for complex byte strings is good and the slowdown for simple byte strings is proportionally small - it might not be worth the hit.

I presume that the MethodHandle adds an overhead.

[pjfanning]

Now have after pjfanning/pekko-test@a79e14f

[info] Benchmark                                 Mode  Cnt       Score        Error  Units
[info] ByteStringBench.newGetInputStream        thrpt    3     816.413 ±    114.507  ops/s
[info] ByteStringBench.newGetInputStreamSimple  thrpt    3  492976.928 ± 145281.777  ops/s
[info] ByteStringBench.oldGetInputStream        thrpt    3     588.401 ±    117.303  ops/s
[info] ByteStringBench.oldGetInputStreamSimple  thrpt    3  490941.644 ± 119759.598  ops/s

[He-Pin]

1. I think we should drop the lazy and just make it a val.
2. the toOption will introduce an allocation, use OptionVal

[pjfanning]

this code is only called once in the whole lifetime of the JVM

[pjfanning]

I think it should be lazy because this code may need to run unless it is needed

[He-Pin]

But the lazy will introduce a volatile iirc, I think this is a trade-off, just not sure if that will cause the problem in the native image.

[pjfanning]

OptionVal does not support changing a Try[A] to an Option[A]. So OptionVal does not look a viable approach here.

[He-Pin]

The getorelse will introduce another closure creation, think we can just fallback to imperative style for performance reason

[pjfanning]

I found that the getOrElse has a small cost so I made a change to remove it

[laglangyue]

LGTM

[He-Pin]

Lgtm