3 ms·

If you are doing real performance coding, you also are avoiding allocations and paying attention to cache sizes and so on. Go is fine for that, hypothetically,

If you are doing real performance coding, you also are avoiding allocations and paying attention to cache sizes and so on. Go is fine for that, hypothetically, though obviously you can do better. But you aren't generating a lot of garbage in the first place so the GC aspect becomes minimal impact. That is, unless you are forced to. One of the things about Go that is _very_ irritating is the way so many key APIs in the ecosystem make it almost impossible to re-use buffers. For example, protobuf and sarama generate throwaway memory at the same rate as message throughput.

richieartoul 4y ago
Yeah that’s true, although there is a growing ecosystem of “allocation sensitive” libraries. We use this one a lot for protobuf: https://github.com/richardartoul/molecule https://github.com/richardartoul/molecule jsonparser is great for JSON parsing: https://github.com/buger/jsonparser https://github.com/buger/jsonparser fastcache is a great “zero gc” cache: https://pkg.go.dev/github.com/VictoriaMetrics/fastcache https://pkg.go.dev/github.com/VictoriaMetrics/fastcache Etc
AlphaSite 4y ago
Go’s GC works well because it has stack allocated types, which Java doesn’t and pays a very heavy penalty for.
- astrange 4y ago
  “Stack allocated” types wouldn’t be a concept at the Java language level, what it’s missing is value types. This has way worse issues than performance, because reference types are unnecessarily mutable and cause lots of bugs. Theoretically it can recover stack allocations with escape analysis though.