This true?
# kotlin-native
k
This true?
👌 1
e
which part?
Kotlin/Native execution is currently much slower than Kotlin/JVM - depends on the task but it can be an order of magnitude or worse. in general JIT can produce near-perfect native code and KN is missing many optimizations - very far from perfect
k
On neat lol
e
for example, look at https://github.com/jorispz/aoc-2020 (via @Joris PZ/#advent-of-code)
😲 1
d
Yeah, I feel a lot of people fail to remember the beast that the JVM is.
k
@Dominaezzz beast how?
d
Refer to the second comment. Can't say it better than that.
👍 2
e
HotSpot JIT is world class and being able to specialize, inline, and deopt at runtime can yield better performance than any ahead-of-time techniques for some applications. (there are also other JIT engines with different abilities, but if you're asking this question it's unlikely that you're using anything other than HotSpot. maybe GraalVM native image or espresso (Java on Truffle) in the future though)
☝️ 1
😲 1
the level of investment in K/N is also incomparable to how many companies and engineers are working on Java's JIT and GC. even standing on LLVM's shoulders, that's no silver bullet.
m
How does it translate to ios specifically? It should not be slower than corresponding swift or objc code, right?
e
it is far slower than the corresponding swift or objc code. performance has not been JetBrains's top priority yet.
😞 1
I don't know their roadmap but I wouldn't expect it before they get the new memory model hammered out
m
Do you happen to know any benchmarks for ios?
e
I don't know of anything modern. I found https://github.com/oboenikui/kotlin-ios-benchmarks/blob/master/results/benchmark-log-throughput.txt but it's 2 years old and there have been improvements since then.
🙏 1
h
An order of magnitude slower?!?! Even pre-JIT Java code wasn't that much slower than C/C++ code.
g
An order of magnitude slower
It highly depends on task, especially previously, many heavy memory pressior operation much slower (which makes sense, in theory GC is always has higher throughput than ARC, and on practice Java GC is highly optimized), also many string-related staff was slow (also related to memory allocation) Anyway, it’s highly related on task