5 ms·
The concurrent map access checks in Go1.6rc1 have already uncovered one such bug in my code. Love it! Oh, and I've already made use of the whitespace-stripping
by dantillberg 11y ago
The concurrent map access checks in Go1.6rc1 have already uncovered one such bug in my code. Love it!
Oh, and I've already made use of the whitespace-stripping in text templates, too! :)
One thing I was worried about from the focus on reducing maximum GC pause times (i.e. latency) was that this might negatively affect GC throughput. For example, maybe the pauses are shorter but there are many more of them. The project I'm working on at the moment exercises the GC heavily but is not concerned with latency (it's bulk data-processing), and I didn't see any significant regression in performance/throughput from 1.5 to 1.6rc1. So, yay.
- mwsherman 11y agoBased on Rick’s talks, this is the sort of trade-off choice one deliberately makes. Reduced throughput can be understood as amortized GC.
- zellyn 11y agoAs I understand it, you would have seen the performance hit going from 1.4 to 1.5.
- pcwalton 11y agoAggressive GC latency improvements, like the ones Go is making, virtually always negatively affect throughput. For example, Azul C4 has lower throughput than HotSpot (at least per the numbers cited in the paper). There's no free lunch in GC.
- FooBarWidget 11y agoBut I would argue that most people who use Go, use it to write user-facing server apps, or at least server apps in which response time is an important metric. I don't know anybody who uses Go to primarily write batch jobs where throughput matters more than latency.
- mike_hearn 11y agoYeah, but that's circular - if you did want to write a high performance batch job, maybe you wouldn't use Go because of the GC. And hi by the way ;)