Open kubukoz opened 10 months ago
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.
Thanks, I appreciate the information!
It'd be interesting to run async-profiler or jfr on the running compiler to try to see if there's an obvious culprit
Good idea, I shall try that.
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:
That sounds promising. I'll test when I find a moment :)
Still takes about 7 seconds to compile in 3.4.2.
Compiler version
3.3.1
,3.4.0-RC1-bin-20231024-15033c7-NIGHTLY
Minimized example
Output
Takes ~7s to compile on an M1 Max machine, ~18s in Scastie.
Expectation
Compiles as fast as this:
which is under a second on my machine.
Extra context
unit
's signature isdef unit[F[_]]: Resource[F, Unit]
as
is a method coming from an implicit conversion, which is brought in viacats.implicits._
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.