2.13 IndexedSeqOps does not override foreach in IterableOps

[som-snytt]

reproduction steps

Issue raised at https://discord.com/channels/632150470000902164/632628489719382036/916066258649243659

LinearSeqOps got some help https://github.com/scala/scala/commit/cc53ceeb6f17fd9606e09d04b0d4b41a36348e90

problem

This is a performance regression with respect to 2.12.

@scala/collections

[som-snytt]

This might be a no-brainer, but other optimizations are not.

For example, List, where it is about dispatch and not algorithmic:

  // Overridden with an implementation identical to the inherited one (at this time)
  // solely so it can be finalized and thus inlinable.
  @inline final override def foreach[U](f: A => U): Unit = {

A tool could help identify methods which are jit- and -opt-friendly, and also which deserve performance testing.

[julienrf]

Thank you for reporting! I am also surprised.

I think it should be possible to add an override in scala.collection.IndexedSeqOps. Ideally, the PR should come with benchmarks results.

[SethTisue]

Issue raised at discord.com/channels/632150470000902164/632628489719382036/916066258649243659

for easy reference, what @WojciechMazur wrote was:

Hey, is here someone with broad knowledge about Scala 2 stdlib (collections)? I've seen a large performance regression in Scala Native between Scala 2.12- and Scala 2.13 collections. In one of my benchmarks, with large number of for-loops, I've seen that replacing seq.foreach with while-loop allows me to drop execution time by half (on the JVM by 20%). Is there some reason why IndexedSeqOps does not override foreach method to use while-loop, but uses default implementation from IterableOps with iterator instead?

[NthPortal]

unassigning myself until it can be shown that there is a concrete and fixable performance problem