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
Verify if the spread operator still has performance impacts #554
Comments
I've run the benchmark, and saw no change with 1.1.60. Looking over it again I realise that KT-20462 only addresses the case when an array constructor function is used with the spread operator, while the linked benchmark passes an array to a method, where they didn't claim any performance improvement. So I think this means:
should no longer suffer array copy performance penalty, but I expect this still does:
The check that was added to the compiler to check for cases where array copy can be skipped is:
That check could be added to SpreadOperator check, and only flag those where above method returns Edit: Note that implementing that change to SpreadOperator requires type and symbol resolving. |
Is this still an issue on 1.3.x? |
The |
I've reconfirmed in 1.3.30, checking the Kotlin bytecode in IntelliJ. When the spread operator is used there's a call of fun doStuff(vararg data: String) {}
fun doStuff2(vararg data: String, moreData: Int) {}
fun doStuff3() {
// no copy for these cases
doStuff(*Array(1) {"a"})
doStuff2(data = *arrayOf("a", "b", "c"), moreData = 3)
// array copied in these cases
val arr = arrayOf("a", "b", "c")
doStuff(*arr)
doStuff2(data = *arr, moreData = 3)
} With type resolution this can be checked based on the method mentioned in my last comment so the case where an array constructor is used will effectively be whitelisted. |
Like mentioned in #546 an issue with the spread operator seems to be fixed KT-20462.
We must rerun the benchmark to verify if the
SpreadOperator
rule is obsolete.The text was updated successfully, but these errors were encountered: