Implicit search optimization possibilities

[retronym]

• ImplicitInfo could cache the deconstructed MethodType, leaving an array of class symbols of the parameter types and the result type. We could then consult this in isPlausiblyCompatible, rather than deconstructing each time a candidate is checked for plausbile compatibility.
• The result of depoly(info.tpe) could be cached in ImplicitInfo rather than being recomputed each time a candidate is considered in matchesPt
• Rather than just considering type refs to class symbols in the fast checks, consider bounds. WIP: Rule out more implicit based on bounds of type parameters scala#6524

[retronym]

Sketching out some ideas here: https://github.com/scala/scala/compare/2.12.x...retronym:faster/implicit-loop?expand=1

[SethTisue]

/cc @milessabin

[milessabin]

This looks like great stuff.

Other things which it might be worth caching,

• the stripped core/covering set of a type.
• the eligible implicits at a given call site/type (might help in inductive cases where the local implicits and stripped core/covering set can be constant across nested searches).
• the result of searches for implicit arguments done to test for the eligibility of an extension method with an implicit argument ... once the view is found the argument is discarded and then immediately searched for again.

[tribbloid]

Hi @milessabin it has been three years, is the idea in this patch already merged into shapeless.CachedImplicitMacro?

[SethTisue]

I'm going to close this since the team at Lightbend isn't currently actively pursuing further Scala 2 compiler optimization opportunities, unless prompted by specific circumstances.

Someone else might still like to explore this.