[tofuahdude]

How "large" is the garbage collector penalty? My understanding is that the Go GC is significantly more efficient than for example JS's mark/sweep approach. Apples to oranges for sure, but I am interested in better understanding how expensive the Go GC is vs Rust performance.

[mihaigalos]

Check out the discord article I posted in the original reply.

If I interpret the graphs correctly, I see:

Golang:

* baseline 20% cpu + spikes to 35% once the GC runs.

* response times of about 1ms + spikes up to 10ms.

Rust:

* baseline 12% cpu + flat, no spiking.

* response times of 20us + flat, no spiking (!).

In terms of scaling, I interpret the results in favor of Rust.

My reasoning is the more you run the GC, the bigger the penalty.

[jhgb]

The question here is how much can you disambiguate between the impact of GC and the impact of differently written code plus differently optimizing compiler backend (where Go is still very simple but Rust uses LLVM). If for example the Go code used goroutines and channels in those places where the rewritten Rust code uses asynchronous operations, that alone may account for substantial differences in performance.

[lossolo]

Posting links to his blog post is misleading in 2022. The issue they mention in their blog was fixed so it's not an issue now.

[mihaigalos]

That's interesting. Would like to read about the solution more. Do you have a reference?

[tofuahdude]

Just read that article; very informative.

The TLDR is that, especially during GC, P99s and response times are notably worse in Go than Rust. Makes sense.

[masklinn]

Go’s GC is not efficient, it is responsive. That is, it trades throughput (and performances, and efficiency) for small pauses and concurrency.