8000 Avoid generic array instantation in hot paths by retronym · Pull Request #5911 · scala/scala · GitHub
[go: up one dir, main page]

Skip to content

Avoid generic array instantation in hot paths #5911

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

Closed
wants to merge 1 commit into from

Conversation

retronym
Copy link
Member

Before:

[info] 
[info] Benchmark                                   (extraArgs)  (source)    Mode  Cnt     Score   Error  Units
[info] HotScalacBenchmark.compile                                         sample  500  1049.371 ± 3.062  ms/op
[info] HotScalacBenchmark.compile:compile·p0.00                           sample       1000.342          ms/op
[info] HotScalacBenchmark.compile:compile·p0.50                           sample       1047.527          ms/op
[info] HotScalacBenchmark.compile:compile·p0.90                           sample       1075.839          ms/op
[info] HotScalacBenchmark.compile:compile·p0.95                           sample       1082.130          ms/op
[info] HotScalacBenchmark.compile:compile·p0.99                           sample       1113.462          ms/op
[info] HotScalacBenchmark.compile:compile·p0.999                          sample       1176.502          ms/op
[info] HotScalacBenchmark.compile:compile·p0.9999                         sample       1176.502          ms/op
[info] HotScalacBenchmark.compile:compile·p1.00                           sample       1176.502          ms/op

After:

[info] Benchmark                                   (extraArgs)  (source)    Mode  Cnt     Score   Error  Units
[info] HotScalacBenchmark.compile                                         sample  500  1045.162 ± 2.888  ms/op
[info] HotScalacBenchmark.compile:compile·p0.00                           sample        984.613          ms/op
[info] HotScalacBenchmark.compile:compile·p0.50                           sample       1046.479          ms/op
[info] HotScalacBenchmark.compile:compile·p0.90                           sample       1068.499          ms/op
[info] HotScalacBenchmark.compile:compile·p0.95                           sample       1075.839          ms/op
[info] HotScalacBenchmark.compile:compile·p0.99                           sample       1090.498          ms/op
[info] HotScalacBenchmark.compile:compile·p0.999                          sample       1117.782          ms/op
[info] HotScalacBenchmark.compile:compile·p0.9999                         sample       1117.782          ms/op
[info] HotScalacBenchmark.compile:compile·p1.00                           sample       1117.782          ms/op

@scala-jenkins scala-jenkins added this to the 2.12.3 milestone May 17, 2017
} else {
val result = new Array[asm.Type](numCapturedParams)
result(0) = typeToBType(lambdaTarget.owner.info).toASMType
capturedParams.iterator.map(sym => typeToBType(sym.info).toASMType).copyToArray(result, 1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a bug here. This loses the last parameter. The array should be numCapturedParams+1 - copyToArray will simply throw away the arguments that do not fix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is numCapturedParams ever 0? If so this could be optimised further.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

8000

Good catch. Turns out the second branch (!isStatic) is never taken, as we chose to make all lambda implementation methods static, which meant we could leave them public without having to mangle the names. But I've pushed a fix in case this becomes live code in the future.

val (capturedParams, lambdaParams) = lambdaTarget.paramss.head.splitAt(lambdaTarget.paramss.head.length - arity)
val invokedType = asm.Type.getMethodDescriptor(asmType(functionalInterface), (receiver ::: capturedParams).map(sym => typeToBType(sym.info).toASMType): _*)
val numCapturedParams = lambdaTarget.paramss.head.length - arity
val (capturedParams, lambdaParams) = lambdaTarget.paramss.head.splitAt(numCapturedParams)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is a special case where arity == 0 which avoid the splitAt

List.splitAt could be optimized where split == 0 and in for Nil - seperate PR probably

@@ -501,7 +501,7 @@ abstract class BCodeHelpers extends BCodeIdiomatic with BytecodeWriters {
currentRun.symData get sym match {
case Some(pickle) if !nme.isModuleName(newTermName(jclassName)) =>
val scalaAnnot = {
val sigBytes = ScalaSigBytes(pickle.bytes.take(pickle.writeIndex))
val sigBytes = ScalaSigBytes(java.util.Arrays.copyOf(pickle.bytes, pickle.writeIndex))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this change - isnt this what .take does as we fixed the Array methods

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. We had to revert that change in #5821 because it wasn't binary compatible. We should re-apply the original patch to the 2.13.x branch.

@retronym
Copy link
Member Author

I"m going to close this PR for now as the benchmark isn't conclusive. I re-ran it and got 1054ms vs 1056ms.

@retronym retronym closed this May 18, 2017
@SethTisue SethTisue removed this from the 2.12.3 milestone Jun 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0