-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Intrinsfy raw and s String interpolators #6093
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
Conversation
Also the following, which I cannot pin down by just looking at the jenkins log: |
4dd601f to
49e4a08
Compare
|
Fixed up the test failure and refactored the implementation some. I'm happy with the 2.12.5 milestone for this one, seems too risky to rush in to 2.12.4. |
| val experimental: NameType = "experimental" | ||
| val f: NameType = "f" | ||
| val s: NameType = "s" | ||
| val raw_ : NameType = "raw" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alphabetical order?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no strong opinion, but it seems the others here are alphabetical indeed.
be070a8 to
a96e4e2
Compare
|
@lrytz Are you happy with the final state of this to target 2.12.5? |
lrytz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, only a few cosmetic cleanups.
| lazy val StringContext_f = getMemberMethod(StringContextClass, nme.f) | ||
| lazy val StringContext_s = getMemberMethod(StringContextClass, nme.s) | ||
| lazy val StringContext_raw = getMemberMethod(StringContextClass, nme.raw_) | ||
| lazy val StringContext_constructor = getMemberMethod(StringContextClass, nme.CONSTRUCTOR) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is unused
| val experimental: NameType = "experimental" | ||
| val f: NameType = "f" | ||
| val s: NameType = "s" | ||
| val raw_ : NameType = "raw" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no strong opinion, but it seems the others here are alphabetical indeed.
|
|
||
| def mkLiteralUnit: Literal = Literal(Constant(())) | ||
| def mkUnitBlock(expr: Tree): Block = Block(List(expr), mkLiteralUnit) | ||
| def mkLiteralString(s: String): Literal = Literal(Constant(s)).setType(StringTpe) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unused
| } | ||
|
|
||
| private object StringContextIntrinsic { | ||
| def unapply(t: Apply): Option[(List[Tree], List[Tree])] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could return an Option[(List[Literal], List[Tree])] to avoid the casts at the use site, though it would require another map in the raw case. Up to you, both ways is fine.
| transform(qual) | ||
|
|
||
| case StringContextIntrinsic(treated, args) => | ||
| var tree: Tree = treated.head |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe call it result to avoid shadowing (and confusion)
a96e4e2 to
72642f6
Compare
lrytz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pushed my review suggestions
|
/synch |
Thanks! |
|
questions: this is intrinsics and not a macro in order to get it into 2.12.x, because bincompat...? and the motivation for getting it into 2.12.x instead of just waiting for 2.13.x is compiler performance...? |
|
Yes, bin compat rules out the macro in 2.12. Source compat, taken strictly,
also makes it had to turn a regular method into a macro in a major release,
but we still plan to do that in 2.13:
https://github.com/scala/scala-dev/issues/475
The compiler already avoided this iniefficiency in really hot code paths,
we didn’t expect nor measure a discernible important time improvement after
this change. But we expected expect application code to benefit (example
where it would have helped: sbt/util#152), hence
the desire to deliver earlier than 2.13
|
|
Nice, forgot about 475! Thx /cc @hrhino |
Boxing and varargs incur a significant penalty for string
interpolation, as explored in:
https://medium.com/@dkomanov/scala-string-interpolation-performance-21dc85e83afd
This pull request takes an initial, big step back towards decent performance
by translating calls to these interpolators to string concatenation, which
itself is already translated to string builder appends in the JVM backend.
I have also tried to be a little smarter with the way we size the string
builder.
Longer term, we should build atop of JEP-280 to extract even better
performance with less code for us to maintain. But that's not available
until Java 9.