His version of "slight" to me isn't so slight. He's brushing under the rug that Go isn't suitable for many of the low latency, memory hungry domains that comprise modern systems.
> many of the low latency, memory hungry domains that comprise modern systems.
I would say it really depends on the situation, and especially what you consider low-latency. It also depends very much on what your definition of low-latency is.
For background: we run a betting exhange. Customers will notice and complain if any action with their money takes more than ~100ms. This threshold aligns quite well with old research about human response times [0].
On the other hand, if we were running an interactive chat/forum system, it would be acceptable to have >500ms latencies from click to comment display. When it comes to communications, reliable persistence tends to be more important to raw latency. (Or to put it another way: it is okay to delay displaying of a fresh comment until it has been stored. That way the user knows they do not need to rewrite their contribution.)
I personally have a background in embedded systems, where hard latency limits are the norm for user experience. Developers, end users and companies are all willing to sacrifice throughput for near-immediate feedback .. and doubly so when the system in question happens to control a vehicle dashboard.
At 60 frames per second, one frame refresh is about 17ms. When you need to provide visibly immediate feedback to the user, you have at most 6 frames to display it. Because the data must be available before the rendering of the 6th frame starts, you actually have on average no more than 5,5 * 17ms = 93ms to calculate the response.
The real trick is figuring out where you can get away with non-immediate latency requirements. And incidentally, this has knock-over effects: if hard low-latency is not necessary, some GC spikes should be tolerable. Spend the engineering effort where it is crucial, not where it might be nice.
At least until you have more workforce than engineering problems.
In the talk Rick described the problem as the data structure responsible for tracking finalizers. The fix is apparently reasonably straightforward, but the cause was not discovered until we were in the Go 1.5 tree freeze, so it has to wait for Go 1.6 in six months.
Hopefully the video will be available soon, it contains a lot of information not in the slides.
> This is assuming the linear relationship holds up
Their goal for 1.6 is to make it constant, not linear:
"Zooming in, there is still a slight positive correlation between heap size and GC pauses. But they know what the issue is and it will be fixed in Go 1.6." https://sourcegraph.com/blog/live/gophercon2015/123574706480