
Kotlin's hidden costs – Benchmarks - pulse7
https://sites.google.com/a/athaydes.com/renato-athaydes/posts/kotlinshiddencosts-benchmarks
======
richdougherty
Summary: most stuff is within 5-10% of Java. In performance sensitive code be
careful of the spread operator and foreach on ranges which have higher costs.

~~~
dcow
Except the parts where Kotlin actually beats Java.

~~~
sk0g
It was still within 5-10%, just on the other end of the scale!

------
jorgemf
If I recall correctly kotlin by default compiles to bytecode of Java 1.6. So o
be afair comparison you should enable kotlin to compile to 1.8. as it is
bytecode anyway I would expect very similar performance. But comparing 1.6
with 1.8 it is obvious 1.6 would be slower.

~~~
pjmlp
The bytecode differences between 1.6 and 1.8 bytecodes are mainly
invokedynamic and methodhandles.

If Kotlin doesn't take advantage of them when targeting 1.8, the bytecode
version won't do any difference.

~~~
jorgemf
My point is that kotlin by default targets 1.6. You need to specify to target
1.8 if you want to use it. So for me the experiment is broken. You should
either compare java 1.6 with kotlin or set up kotlin to use 1.8 to compare
with the same java version.

------
lgleason
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.

~~~
matt4077
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
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
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
"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!

------
StreamBright
Excellent news, Kotlin is getting to be a real option on the JVM.

------
aplummer
I've never had to program so efficiently where this kind of thing would matter
- only ever optimizing for readability and correctness in terms of bugs.

For people who do, do you enjoy performance optimization or does it get
tedious?

~~~
sgift
Bit of both. I don't have to do it often and when you really need to press all
the performance you can get out of some code it can be really maddening when
there is no "obvious" reason. Quite often it is just an accumulation of many
very small slowdowns which together are significant and then the measure,
change, measure, change, measure ... loop can be very tedious. Sometimes,
there are interesting things like changing the whole algorithm to something
which performs better or reading up on bit-fiddling tricks which make some
code remarkably faster (Hacker's Delight is not for the faint of the heart,
but an interesting book nonetheless).

------
Unknoob
Really wish the author labeled the axes. Took me way longer than I care to
admit to figure out what the graphs meant.

~~~
chrisseaton
Isn't the relevant thing the relative value? What information are you getting
from the absolute value which is the only thing you'd need a label for, given
the author says taller is better? (We'd assume linear unless otherwise
specified.)

------
jankotek
I write performance sensitive code in Kotlin. Most of those issues are common
to Java8 and be worked around easily.

------
arrty88
if it's still faster than javascript / nodeJS, we're in a good place.

------
time4tea
Clickbait.

It's the same.

Unless you care about a particular use case, when it isn't.

Measure, profile, refactor....

~~~
darylteo
The title is a response to another blog series called "Exploring Kotlin’s
hidden costs". He is benchmarking the claims in those blog posts. Title Gore,
perhaps. But not clickbait in this case.

