On Sun, Feb 28, 2016 at 11:56 AM, Andy wrote:
Yes, Go is the GC language, however, should we let the Go itself to take
care of the memory management?
I would let the GC handle memory management until you can demonstrate your
problem would benefit from using another method. At that point, you may
find that a rewrite using sync.Pool is fast enough. If that fails, and you
can demonstrate you need the extra performance, drop to handling your own
The price of doing such work yourself is much lower productivity as a
In earlier Go versions, 1.4 and before, isolating part of the memory space
in order to improve pause time latency was sometimes needed. In 1.5 and 1.6
you shouldn't do that to get lower pause time latencies as the GC only
blocks the world when it gets close to mark termination, and doesn't keep
the block for long, even for massive heaps of several hundred gigabytes in
The sacrifice for the low pause time latencies are slower throughput of the
program in general. So it may still be that your problem needs to isolate
part of the heap so it doesn't allocate and force the GC work upon you. But
this can often be alleviated by adherence to the principle of not
allocating data in the first place and using sync.Pool in the critical
bottleneck parts of the program.
In short: study the GC of the programming language you use. Write the
program so it is not in opposition to the GC, and your program will often
be fast. You usually have to do some extraordinary work in order to beat
the GC algorithm and a simple naive approach is often slower than just
using the GC like it was intended to be used.
Also beware of just measuring the critical loop and heed Amdahl's law. Real
programs allocate in all kinds of places so it may be more beneficial to
the overall performance to fix allocation rates in other parts of the
system first. My experience is that larger programs are more susceptible to
bad performance due to unforeseen outliers in the 99th percentile of
operation than in their main loop. And improving the 99th percentile can
often improve the overall system behavior, even if it comes at a cost to
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.