scala
Slow performance in a combination of features
Compiler version
3.3.1, 3.4.0-RC1-bin-20231024-15033c7-NIGHTLY
Minimized example
//> using scala "3.4.0-RC1-bin-20231024-15033c7-NIGHTLY"
//> using lib "org.typelevel::cats-effect:3.5.2"
package demo
import cats.effect.IO
import cats.effect.kernel.Resource
import cats.implicits._
val demo: Resource[IO, Unit] = Resource.unit.as(???)
Output
Takes ~7s to compile on an M1 Max machine, ~18s in Scastie.
Expectation
Compiles as fast as this:
//> using scala "3.4.0-RC1-bin-20231024-15033c7-NIGHTLY"
//> using lib "org.typelevel::cats-effect:3.5.2"
package demo
import cats.effect.IO
import cats.effect.kernel.Resource
import cats.implicits._
val demo: Resource[IO, Unit] = Resource.unit[IO].as(???)
which is under a second on my machine.
Extra context
-
unit's signature isdef unit[F[_]]: Resource[F, Unit] -
asis a method coming from an implicit conversion, which is brought in viacats.implicits._ - The code doesn't compile on Scala 2.13 because
unit's parameter is simply not inferred at all (I suppose it's just the new inference algorithm)
I believe the slowdown is a combination of trying to infer unit's type parameter (which is a type constructor, potentially complicating inference) from a Scala 2 implicit conversion.
The main problem with this issue is that it's not only slowing down the actual compilation process (for my runs or tests), but also affecting all Metals functionality - completions timing out and similar.
Mixing type inference, higher-kinded types and implicits leads to difficult situations. Getting rid of one of those 3 factors, such as adding explicit types, seems to be the right thing to do, here.
It could be improved in the future but it is unlikely that this will be worked on by the core team.
@kubukoz We are currently lacking the resources to take on hard stuff like this issue. The Scala Center has launched a fund-raising campaign. If that is successful it would change the situation. We could hopefully work on this if new advisory board members find it important.
It'd be interesting to run async-profiler or jfr on the running compiler to try to see if there's an obvious culprit
Hey @kubukoz, there were some improvements made to the performance of implicit search in #19563. Not sure, but maybe there's a chance that it helped with this issue as well? :slightly_smiling_face:
Would be great if compiler could report on time spent compiling each artifact. I'm happy to add explicit types, etc but how would you even know this was an issue in a project of 1000 source files?
