Stream.fromIterator doesn't create proper chunks

[susuro]

Stream.fromIterator fetches values one by one, effectively creating single-value chunks. This has negative impact on performance, especially when working with primitive values.
The situation is even worse for Stream.fromBlockingIterator, because context switch for each fetched value increases the performance penalty.

I think this could be improved with following implementation of PartiallyAppliedFromIterator:

private[fs2] final class PartiallyAppliedFromIterator[F[_]](
    private val dummy: Boolean
) extends AnyVal {
  def apply[A](iterator: Iterator[A], chunkSize: Int = 1)(implicit F: Sync[F]): Stream[F, A] = {
    def getNextChunk(i: Iterator[A]): F[Option[(Chunk[A], Iterator[A])]] =
      F.delay {
        for (_ <- 1 to chunkSize if i.hasNext) yield i.next()
      }.map { s =>
        if (s.isEmpty) None else Some((Chunk.seq(s), i))
      }

    Stream.unfoldChunkEval(iterator)(getNextChunk)
  }
}

Similarly with PartiallyAppliedFromBlockingIterator.

If you find this solution OK I would be happy to prepare and submit a PR.

[mpilquist]

Any thoughts on Stream.fromIterator(iterator).chunkN(n) instead?

[djspiewak]

Any thoughts on Stream.fromIterator(iterator).chunkN(n) instead?

It's more general, but it would incur the chunk management overhead. It's going to be significantly slower than batching next calls within a tight loop. I'm a little skeptical of using Iterator in performance-sensitive code to begin with, but if you are, then chunkN isn't going to solve the problem.

[susuro]

I haven't done proper performance testing, only a few tests within a CSV parsing library, so my claims below my not be fully correct. However, the processing time I've measured for Stream.fromIterator(iterator).chunkN(chunkSize).flatMap(Stream.chunk) is about 2x shorter that using simple Stream.fromIterator(iterator), while the tight loop I proposed gives me 10x better result.
In case of fromBlockingIterator, chunkN doesn't provide any significant improvement while tight loop executes 100x faster.

You're probably right that we should avoid using iterator for performance-sensitive operations. But sometimes, in existing projects, the iterator may be the only interface you have available and even if the code isn't really performance-sensitive, making it more efficient can still be valuable.

[mpilquist]

OK, let's move on to a PR then. Thanks for testing.

[susuro]

Solved wit PR #2013.