opentelemetry-java VS jmh

After doing some research it appears this class references internal packages and therefore "makes it unusable for modern Java apps" (https://github.com/prometheus/client_java/issues/533 , https://github.com/open-telemetry/opentelemetry-java/issues/4192)

For monitoring: If you want to go the open source route, the open telemetry ecosystem is booming. You could use the open telemetry java agent along with their collector, and then use Elastic APM, which could give you a good starting point. Here is a small example project I found on github that was fun to play around with and explore the capabilities of a setup like this: https://github.com/riferrei/otel-with-apache-pulsar

OpenTelemetry and Java Flight Recorder (JFR) cover most bases. Use the OpenTelemetry Java agent if you want auto-instrumentation or just the APIs if you want to do your own instrumentation.

opentelemetry-java - contains components for manual instrumentation as well as the API and SDK.

opentelemetry-java This repo is the main OpenTelemetry Java SDK and provides components for manual instrumentation. Top-level components include OpenTelemetry API, extensions, SDK, bridge layers for OpenTracing and OpenCensus.

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.

Let's run some Java Microbenchmark Harness (JMH) benchmarks to compare the performance of JNI and Panama API. We will use the getpid function from the standard C unistd header for the comparison. We will call the API using JNI and Panama APIs and compare the performance. I'm running the benchmark on Linux with OpenJDK 19 early access build for Panama (openjdk 19-panama 2022-09-20).