[vohvae]

I haven't looked at the benchmark implementations but one particular area I've heard other languages to lag behind java is cost of allocation.

Since openjdk has had to cope with lack of (user defined) value types and the garbage heavy ecosystem it has a very well optimised GC for handling heap allocations.

I wonder if the results will be different if other language benchmarks (C++ or rust) use different allocators (eg: bump allocator, per request collectors) for cheaper allocation.

[capableweb]

Most of the compared languages (except C#) are likely to lag behind Java on many things, performance included, since Java has been around since 1996, Golang only been around since 2009 and Rust 2010. More time = more engineering time to optimize.

[qalmakka]

While this _could_ be correct if we are just talking about Go, which has its own backend and optimizer, it is definitely not the case for Rust, which uses LLVM. The differences seen in these benchmarks are all about the gRPC implementation used; languages are irrelevant. C++, Rust, Go and Java all have their own standalone implementation written from scratch, so it's kind of an apples and oranges situation here. You can write good or crummy code in any language for what it's worth.

[capableweb]

I agree with you and I think we're both right here, on both measures :)

[paavohtl]

This comparison is more about the different gRPC implementations rather than the languages. There is no inherent reason why Java (as a language) should be faster than C++ or Rust in a benchmark like this. A lot of time and money have been spent optimizing Java (or HotSpot), but only because Java is really hard to optimize compared to GC-less low level languages.

[habibur]

Ref counting is more efficient than any GC allocator, which is generally the default in C++.

[qalmakka]

I don't know, is it though? Properly done reference counting AFAIK requires using atomic increase/decrease in order to be safe, and that creates a bit of overhead every time you assign a reference, while assignment to a reference with a precise GC is basically a pointer assignment. It's much better for latency though, given that the overhead from rc is deterministic. It has been a few years though since I've looked into garbage collection techniques, so I could be a bit rusty about the current state of the art.

[paavohtl]

You only need atomic reference counting if you're sharing objects between multiple threads, but if you use an object from one thread at a time then non-atomic inc/dec is enough. Rust allows you to make the choice between the two kinds and the compiler can infer which kind you need to use.

[qalmakka]

Yeah - Rust can, because it also ensures you can't exchange data unsafely between threads, but C++ can't. That's why `std::shared_ptr` has to be thread-safe.

[gher-shyu3i]

Not necessarily. Bump allocations are extremely cheap, and collections can be batched to avoid interruption and performance impact.