Skip to content
0:00 / 0:00

#kotlin#jvmbytecode#benchmarking

KotlinConf 2017 - The Cost of Kotlin Language Features by Duncan McGregor

JetBrains

236K subscribers • 29 videos on Hallway

YouTube
  • Recommended by 3 people: 3 in engineering communities.
  • Presented by Duncan McGregor

Advanced. Deep dive for people who know the field.

8.6K views8 years ago3 recommendations

Programming languagesSystems programmingKotlinPerformance and optimizationCompilers and interpreters

Duncan McGregor analyzes the JVM bytecode generated by the Kotlin compiler and shares benchmark results to measure performance overhead.

It's easy to appreciate the productivity gains of Kotlin, but what are the downsides in code size and execution time? In this session I look at the (JVM) code generated by the Kotlin compiler and benchmark results to help answer these questions. Duncan has been programming professionally for 25 years. He was lucky enough to ride the Object-Oriented wave of the 90s, the Agile wave of the 00s, and what he is convinced will be called the Distributed-Functional wave of the, erm 10s.

Why it's here

3 people recommend this

What people say. Recommended for understanding the performance and bytecode overhead of Kotlin features like lambdas and collections.

u/GingerDeadshotin r/Kotlin • Recommends

On “I like Kotlin for its concise, clean syntax and null safety. What I’m a bit skeptic of is it’s auto boxing primitive and possibly other gotchas when running on a memory constrained server environment. Has anyone of you observed any gc troubles? Are you using any particular jvm knobs/switches etc?”

link to this video TL;DW: Kotlin's language features may sound expensive, but they rarely have any performance impact, and when they do, the impact is extremely small. You shouldn't have any problems.

u/dmcgin r/Kotlin • Recommends

On “Collections Functions, Kotlin, and Performance”

Whether to convert to a Sequence or just call map, filter etc on an Iterable and suffer the creation of intermediate Lists will depend on the details of your algorithm and the size of your data. In my testing I found both generally faster than using Streams, unless you are using primitives, where Kotlin can suffer boxing overhead. You could check out my talk at KotlinConf link to this video for some results and how to measure for yourself.

u/tarkaTheRotterin r/Kotlin • Recommends

On “Does Kotlin slow down our code? [video]”

Also on the same subject from KC2017: [video

u/dmcgin r/Kotlin • Mentions

On “Threads vs Coroutines - ParallelMap Performance”

In the last episode we implemented a parallelMap operation using streams, raw threads, a threadpool with futures, and coroutines. At first glance the raw threads was quickest, followed by futures, coroutines and then streams. In this, part 56 of an exploration of where a Test Driven Development implementation of the Gilded Rose stock control system might take us in Kotlin, we investigate the performance of the different functions further, in particular digging down into why coroutines seem to be slow and finding a way to speed them up. We also find a way to use a particular ForkJoinPool to run the streams code, making it as fast as the others (bar the raw threads). Frankly we only use…