async-profiler VS jmh

Using the Async Profiler we were able to build flamegraphs for the first and second queries to picture the differences in path length of the two transactions execution.

Also, running it under a profiler (I recommend async-profiler[1]) should give you a good idea of where the slowdown occurs which might help you pin it down further.

[1] https://github.com/jvm-profiling-tools/async-profiler

async-profiler is really great at analyzing allocations, give it a shot!

JFR to Flame Graph Converter

Async Profiler converter tool does support JFR to Flame Graph, JFR to FlameScope, collapsed stacks to Flame Graph -https://github.com/jvm-profiling-tools/async-profiler#download

JMH for benchmarks

I would recommend using JMH instead.

Aleksey Shipilev is another such leader, whom is especially knowledgeable about the internals of the JVM. His writings are invaluable. He is (was) the lead of the Java microbenchmark framework (JMH} which is how one would write small performance experiments in Java, and learn what really makes a difference or now.

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 very rough benchmarks here, with no statistical testing except 'it looks like'. That's OK for gross differences, but is highly suspect when deciding which of two similarly performant approaches is faster. For that check out JMH and you could watch my video from KotlinConf 2017

A few months ago, we started to use JMH in our project to test and find performance issues. The tool provides multiple modes and profilers, and we found this useful for our purposes.

This is where JMH is coming to the stage.

Use jmh for microbenchmarks -> https://github.com/openjdk/jmh

In practice you don't know which one is faster except for very large n. Would be interesting to benchmark the clojure data structures with jmh and the .net immutable data structures with benchmarkdotnet for different n and compare the results.