Again, in my case it’s not about the performance, it’s about the garbage. It is not really important to me how much non-boxing would improve my performance in terms of throughput, so I never measured the relative computing share. I guess it’s negligible. But the garbage that gets produced as a side product of boxing is enormous, since the GC runs every few seconds and pauses the system for like 1ms-2ms. And I can see in the profiler/sampler that pretty much all garbage comes from boxing (as I am pooling and reusing all other frequently used objects).
Of course it’s possible to find these boxing events manually, but it’s surprisingly annoying to do this in Kotlin (compared to Java) since the former is less explicit about boxing. It’s unfortunate because the JVM is a great platform for projects like mine. You can write normal, high-level code for methods that are not called frequently, and focus on speed (pooling, primitives, cache awareness) for the parts where it matters. All without switching to a low-level language while still being close in terms of performance. A good example for that is Rapidoid, which is a Java web framework that is on par with the fastest C++ framework out there.