Multiple Vector.slice over each other slow things down

[JaroslavTulach]

Pull Request Description

Fixes #11859 by unwrapping results of previous Vector.slice before doing another slice.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Scala,
  Java,
• Benchmarks measured and improved

[JaroslavTulach]

The current benchmarks results are here:

Benchmark                                    Mode  Cnt    Score    Error  Units
VectorBenchmarks.averageAbstractList         avgt    5    0.053 ±  0.007  ms/op
VectorBenchmarks.averageOverArray            avgt    5    0.001 ±  0.001  ms/op
VectorBenchmarks.averageOverArrayProxy       avgt    5    0.001 ±  0.001  ms/op
VectorBenchmarks.averageOverArrayProxyNew    avgt    5    0.001 ±  0.001  ms/op
VectorBenchmarks.averageOverPolyglotArray    avgt    5    0.001 ±  0.001  ms/op
VectorBenchmarks.averageOverPolyglotVector   avgt    5    0.001 ±  0.001  ms/op
VectorBenchmarks.averageOverSlice            avgt    5    0.001 ±  0.001  ms/op
VectorBenchmarks.averageOverSliceWrapped10   avgt    5    0.073 ±  0.002  ms/op
VectorBenchmarks.averageOverSliceWrapped100  avgt    5  254.710 ± 46.822  ms/op
VectorBenchmarks.averageOverVector           avgt    5    0.001 ±  0.001  ms/op

as can be seen averageOverSlice is as fast as direct access. averageOverSliceWrapped10 is 70x slower and averageOverSliceWrapped100 completely bailed out on the compilation. Time to make things faster.

[JaroslavTulach]

This benchmark run shows that

• VectorBenchmarks_averageOverSlice takes 0.0014021641678018011 s
• VectorBenchmarks_averageOverSliceWrapped10 takes 0.10331784013080388 s

e.g. there is something to speed up. ba0593a helps a lot, but uncovers a problem of "Insert Node" which converts Vector.Long into Vector.Generic. Accessing generic references is indeed slower than accessing long[] behind Vector.Long. New benchmark run has been scheduled.

[JaroslavTulach]

@4e6, with the here-in proposed change ba0593a your project finishes in a few seconds:

sbt:enso> runEngineDistribution --jvm --run Text_Find_Bench
...
lines remain: 7
lines remain: 3
960
[success] Total time: 11 s, completed Dec 28, 2024, 6:46:13 AM

in this case 11s.

[Akirathan]

OK. But I don't understand what findStorage should actually do, with this weird infinite loop?