Derive typeclasses via Coercible hurts compiler performance?

Since the introduction of newtypes in conjuction with refined I see a big increase in compilation time. Especially in my postgres module. I was using refined before in my postgres module, but not with newtypes. I’m using doobie and SQL/fragment interpolated strings to construct queries. The string interpolator of doobie summons foreach interpolated variable a Put type class (which is used to convert the variable being interpolated to a JDBC data type).

Here’s the code to convert newtypes to Put and Get (for reading data from JDBC)

  implicit def coerciblePut[N, P](implicit ev: Coercible[Put[P], Put[N]], R: Put[P]): Put[N] = ev(R)
  implicit def coercibleGet[N, P](implicit ev: Coercible[Get[P], Get[N]], R: Get[P]): Get[N] = ev(R)

I’ve included the scalac-profiling aswell: https://gist.github.com/Fristi/363e7fcf8f899e24eae53d42d741fd13

It seems to not have repeeated expansions, but rather unique expansions

[joroKr21]

Idk it’s hard to tell without looking at the codebase. But perhaps eliminating implicit searches like these:

         "io.estatico.newtype.Coercible[doobie.util.Put[P],doobie.util.Put[courier.core.DepotName]]" -> 1,
         "io.estatico.newtype.Coercible[doobie.util.Put[P],doobie.util.Put[java.time.LocalDate]]" -> 1,
         "io.estatico.newtype.Coercible[doobie.util.Get[P],doobie.util.Get[courier.core.VacancyId.Type]]" -> 1,
         "io.estatico.newtype.Coercible[doobie.util.Put[P],doobie.util.Put[StringContext]]" -> 1,

[carymrobbins]

That’s the trick I’ve learned in Haskell as well 😃 I didn’t know that would be so bad? It saves a ton of code though.

In Haskell you should probably prefer StandaloneDeriving with GeneralizedNewtypeDeriving

-- Package A
newtype Text = Text String

-- Package B
deriving newtype instance Put Text

Yes, it can be boilerplatey if you have a lot of them, but it’s a bit safer this way. It might not always be the case that you wanted an instance for some particular newtype, or even that instance. Always better to define them explicitly. So in Scala, I recommend a similar strategy for the same reasons.

Happy to have this resolved though, builds are much faster 😃

Fantastic!