-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Performance of compiletime tuple construction #15988
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The new implementation instantiates the TupleN/TupleXXL classes directly. This avoids the expensive construction of tuples using `*:`. Fixes scala#15988
The new implementation instantiates the TupleN/TupleXXL classes directly. This avoids the expensive construction of tuples using `*:`. Fixes scala#15988
The new implementation instantiates the TupleN/TupleXXL classes directly. This avoids the expensive construction of tuples using `*:`. Fixes scala#15988
The new implementation instantiates the TupleN/TupleXXL classes directly. This avoids the expensive construction of tuples using `*:`. Fixes scala#15988
The new implementation instantiates the TupleN/TupleXXL classes directly. This avoids the expensive construction of tuples using `*:`. Fixes scala#15988
The new implementation instantiates the TupleN/TupleXXL classes directly. This avoids the expensive construction of tuples using `*:`. Fixes scala#15988
The new implementation instantiates the TupleN/TupleXXL classes directly. This avoids the expensive construction of tuples using `*:`. Fixes scala#15988
The new implementation instantiates the TupleN/TupleXXL classes directly. This avoids the expensive construction of tuples using `*:`. Fixes scala#15988
The new implementation instantiates the TupleN/TupleXXL classes directly. This avoids the expensive unrolling of tuples using `*:` recursively. Fixes #15988
Hi there - just wondering: how are the chances of having the fix backported to 3.3.x? The reason I am asking: the fix does not only improve compiletime, it also improves the capabities of Mirror-bases typeclass-derivation regarding the "Maximal number of successive inlines (32) exceeded" limitation. For example, one can rewrite inline def summonInstances[Elems <: Tuple]: List[Eq[?]] =
summonAll[Tuple.Map[Elems, Eq]].toList.asInstanceOf[List[Eq[?]]] With that change and Scala version 3.4.0 or higher (i.e. , those that include the fix from #18013), it is possible to derive instances for product and sum types with an arbitrary number of members without hitting "Maximal number of successive inlines (32) exceeded". See https://scastie.scala-lang.org/Or2yo9GCROuE31lfePTzWQ for such rewrite of the Eq example (with an example case class that would fail to compile with 3.3.5 due to successive inlines). |
Compiler version
3.2.0
Minimized example
Tuple construction through
constValueTuple
,summonAll
and probably others too currently run in quadratic time at runtime, constructing all the smaller tuple sizes before getting to the desired one.Decompiled Java
Expectation
The text was updated successfully, but these errors were encountered: