Looking at the byte code it seems like there is `A...

# announcements

[robstoll]

Looking at the byte code it seems like there is Array.copy involved in the following statement:

fun foo(vararg path: String) = Paths.get(*path)

Is there a way to pass an array to Paths.get as it is possible in Java in order to circumvent the performance penalty?

[Ruckus]

Out of curiosity, have you actually noticed a performance penalty? I ask because, from my experience, most people who have such a question have read that there is a performance penalty and go crazy trying to get rid of it without checking how it stacks up to the rest of their app. The copy call is very efficient, and I've never seen a situation where the "penalty" is remotely close to a problem, especially compared with other bottlenecks.

[Sam]

you could define foo to take a string array

[robstoll]

@Ruckus its part of a small library, so I am not the one experiencing the penalty but others could. If the penalty is significant is another question and I asked more out of curiosity as well 😉

[Ruckus]

I can tell you from my experience, the penalty has never been significant (the JVM is really efficient at copying arrays), and the benefits are great (in Java it was always recommended to create a defensive copy anyway to avoid issues from external manipulation).

[robstoll]

I totally agree with you. Yet, there is no need for a defensive copy in the above case . I am not using path a second time in the function and have already a copy of path (or is it possible to pass somehow not a copy to the function - maybe from Java 🤔)

[orangy]

I wonder if making foo inline would help.

[robstoll]

nope

[robstoll]

https://youtrack.jetbrains.com/issue/KT-27538

[orangy]

Well, you need to actually look at what JIT makes out of this bytecode… Or write some trivial JMH benchmark and test it.

[robstoll]

that's true, but AOT is still better than JIT no?

[orangy]

Well, if it doesn’t break anything, that yes