-5

It's widely accepted that one of the main things holding Go back from C++ level performance is the garbage collector. I'd like to get some intuition to help reason about the overhead of Go's GC in different circumstances. For example, is there nontrivial GC overhead if a program never touches the heap, or just allocates a large block at setup to use as an object pool with self-management? Is a call made to the GC every x seconds, or on every allocation?

As a related question: is my initial assumption correct that Go's GC is the main impediment to C++ level performance, or are there some things that Go just does slower?

rampatowl
  • 1,260
  • 1
  • 9
  • 26

1 Answers1

2

The pause time (stop the world) for garbage collection in Golang is in the order of a few milliseconds, or in more recent Golang less than that. (see https://github.com/golang/proposal/blob/master/design/17503-eliminate-rescan.md)

C++ does not have a garbage collector so these times of pauses do not happen. However, C++ is not magic and memory management must occur if memory for storing objects is to be managed. Memory management is still happening somewhere in your program regardless of the language

Using a static block of memory in C++ and not dealing with any memory management issues is an approach. But Go can do this too. For an outline of how this is done in a real, high performance Go program, see this video

https://www.youtube.com/watch?time_continue=7&v=ZuQcbqYK0BY

Vorsprung
  • 28,957
  • 4
  • 32
  • 55
  • Hey, thanks for the reply--the video was helpful. To clarify, can you get a soft guarantee that you'll never get hit with the pause time if you have a tiny amount of total allocations? – rampatowl May 11 '18 at 16:15