High Overhead - MessageDigest

[etspaceman]

Bringing this up per a discord conversation with @armanbilge , @djspiewak and @mpilquist .

I was looking to use hashing functionality in FS2 as I believe it is one of the (if not the) only Scala Native / Scala.js compliant abstraction for hashing.

However, it seems that the definition will call MessageDigest.getInstance on every invocation of the Pipe. This has a very high overhead. References:

https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html
svroonland/zio-kinesis#732
https://bugs.openjdk.org/browse/JDK-8259065 (slight improvement via caching in Java 17)

For me, this was problematic, as I was going to be calling that pipe several times (e.g. hash this record). It looks like Java 17 is going to start caching default constructors, but many users are likely still on older java versions, and using this would incur a pretty high cost.

Something we could do is leverage https://github.com/typelevel/keypool to create our own cache of MessageDigest instances. This could substantially lower the overhead of these offerings.

Important to note that MessageDigest must have its reset() function invoked before it is re-used.

[armanbilge]

I wonder if we can just cheat by having an AtomicReference[List[MessageDigest]]. Every time the stream is invoked it can pop a digest off of that, and when it's done, it can pop it back on.

Cheating because:

1. global state
2. it would be leaning into Stream.suspend
   

   fs2/core/shared/src/main/scala/fs2/Stream.scala

   Lines 3910 to 3911 in 26b011d

   	def suspend[F[_], O](s: => Stream[F, O]): Stream[F, O] =
   	Pull.suspend(s.underlying).streamNoScope

[etspaceman]

Isn't that effectively what keypool does? What's the advantage of rolling our own here?

[armanbilge]

Putting aside the issue of keypool specifically, doing anything more than this has two issues:

1. it requires typeclass constraints. hash currently has no constraints.
2. getting a hash function is now effectful, since it involves shared state. i.e. you'd have to get a F[md5], instantiate it at the beginning of your program, and pass it around.

[etspaceman]

I would think 2 would be needed regardless, as an AtomicReference[List[MessageDigest]] would need to be constructed somewhere

[armanbilge]

Hence, cheat (1) :) I say just put it in the hash object.

[armanbilge]

My bigger take-away here is that we are stretching the limits of what fs2.hash can do without a more fundamental redesign. And I'm not sure such a thing belongs in FS2 anyway. We are still needing that Typelevel crypto library :)

[etspaceman]

I would probably agree with this. Either a separate library or just having it in CE would make sense to me.

[mpilquist]

I don't think fs2 should have a dependency on keypool. If the improvements in Java 17 address all or most of the issue, then I think we should keep things as-is.