3 ms·

Over time Kotlin's performance numbers will improve. For most applications though the small performance cost will be outweighed by the increased time to market

Over time Kotlin's performance numbers will improve. For most applications though the small performance cost will be outweighed by the increased time to market and improved null handling.

hobo_mark 9y ago
*decreased time to market (I assume)
matt4077 9y ago
Yeah, that's the go-to answer for slow runtimes... In this case, "5-10% just isn't that much" may be the better excuse. Since Kotlin runs on the same jvm, it is a subset of Java, and therefore impossible for Kotlin to create code (and achieve speeds) that Java couldn't match. In practice, Kotlin should asymptotically approach the performance of best-practice Java code, with possible performance improvements when it can correct unoptimised code, or implements new Java features without requiring any manual refactoring.
- mobiletelephone 9y ago
  I agree with your conclusion, but it actually could be possible for kotlin to be faster than java for practical purposes, despite running on the JVM. For example, it might be more expressive, allowing the user to give the compiler more information for better optimizations. We see this when C++ is sometimes faster than C.
  - mike_hearn 9y ago
    Kotlin code can be and sometimes will be faster than the equivalent Java code because Kotlin does lambda inlining on the frontend and does not rely on the JVM to do so. That probably helps a lot, because it takes significant machinery in the profiling and JIT compilers to automatically eliminate the overhead of higher-order functions and the JVM can't always do it due to a problem called "profile pollution". Kotlin pushes a bit of the thinking onto developers, albeit aided by type hints, and then does the inlining itself in many cases. Especially helpful on platforms with weaker JVMs like older Androids (the upcoming Android update appears to have improved ART so significantly that it's now a serious competitor to HotSpot). Whilst the article doesn't show any difference in lambdas I wouldn't expect it to show up in micro-benchmarks like this one because the profile pollution problem wouldn't occur. In any real app it would show up though. Also when Kotlin inlines on the frontend it can also use reified generics in a few cases. Finally, Kotlin provides features that developers can use to write more efficient code, I'm thinking about how easy it makes lazyness in particular. Whilst you always can write equivalent code in Java, it takes more effort to do so, meaning developers probably won't always bother.
    - buremba 9y ago
      "Finally, Kotlin provides features that developers can use to write more efficient code, I'm thinking about how easy it makes lazyness in particular. Whilst you always can write equivalent code in Java, it takes more effort to do so, meaning developers probably won't always bother." -> Agreed!
- elgenie 9y ago
  > Since Kotlin runs on the same jvm, it is a subset of Java, and therefore impossible for Kotlin to create code (and achieve speeds) that Java couldn't match. This doesn't follow for several reasons. First, there are JVM bytecodes that Java doesn't use, so it would be more accurate to say that JVMLangX and Java both target subsets of the JVM. Second, higher order constructs could allow a JVMLangX-to-bytecode compiler to enforce checks at compile-time that would need to be done at runtime in Java.

Over time Kotlin's performance numbers will improve. For most applications though the small performance cost will be outweighed by the increased time to market and improved null handling.

hobo_mark 9y ago

*decreased time to market (I assume)

matt4077 9y ago

Yeah, that's the go-to answer for slow runtimes... In this case, "5-10% just isn't that much" may be the better excuse. Since Kotlin runs on the same jvm, it is a subset of Java, and therefore impossible for Kotlin to create code (and achieve speeds) that Java couldn't match. In practice, Kotlin should asymptotically approach the performance of best-practice Java code, with possible performance improvements when it can correct unoptimised code, or implements new Java features without requiring any manual refactoring.

mobiletelephone 9y ago
I agree with your conclusion, but it actually could be possible for kotlin to be faster than java for practical purposes, despite running on the JVM. For example, it might be more expressive, allowing the user to give the compiler more information for better optimizations. We see this when C++ is sometimes faster than C.
- mike_hearn 9y ago
  Kotlin code can be and sometimes will be faster than the equivalent Java code because Kotlin does lambda inlining on the frontend and does not rely on the JVM to do so. That probably helps a lot, because it takes significant machinery in the profiling and JIT compilers to automatically eliminate the overhead of higher-order functions and the JVM can't always do it due to a problem called "profile pollution". Kotlin pushes a bit of the thinking onto developers, albeit aided by type hints, and then does the inlining itself in many cases. Especially helpful on platforms with weaker JVMs like older Androids (the upcoming Android update appears to have improved ART so significantly that it's now a serious competitor to HotSpot). Whilst the article doesn't show any difference in lambdas I wouldn't expect it to show up in micro-benchmarks like this one because the profile pollution problem wouldn't occur. In any real app it would show up though. Also when Kotlin inlines on the frontend it can also use reified generics in a few cases. Finally, Kotlin provides features that developers can use to write more efficient code, I'm thinking about how easy it makes lazyness in particular. Whilst you always can write equivalent code in Java, it takes more effort to do so, meaning developers probably won't always bother.
  - buremba 9y ago
    "Finally, Kotlin provides features that developers can use to write more efficient code, I'm thinking about how easy it makes lazyness in particular. Whilst you always can write equivalent code in Java, it takes more effort to do so, meaning developers probably won't always bother." -> Agreed!
elgenie 9y ago
> Since Kotlin runs on the same jvm, it is a subset of Java, and therefore impossible for Kotlin to create code (and achieve speeds) that Java couldn't match. This doesn't follow for several reasons. First, there are JVM bytecodes that Java doesn't use, so it would be more accurate to say that JVMLangX and Java both target subsets of the JVM. Second, higher order constructs could allow a JVMLangX-to-bytecode compiler to enforce checks at compile-time that would need to be done at runtime in Java.