The blogpost talks about one performance critical service specifically, not the whole of Discord, but I found it interesting that Go's GC became a problem at that scale with no way to tune it...
The blogpost talks about one performance critical service specifically, not the whole of Discord, but I found it interesting that Go's GC became a problem at that scale with no way to tune it other than rewriting a bunch of code with not much profit.
This is definitely the place where Go can improve the most. GC should be more tunable from the go run and go build commands instead of having to trick it into doing what you want in code.
This is definitely the place where Go can improve the most. GC should be more tunable from the go run and go build commands instead of having to trick it into doing what you want in code.
Based on discussion on Hacker News, apparently they started this migration when Go 1.9 was current. There have been significant improvements to Go's garbage collection since then, particularly in...
Based on discussion on Hacker News, apparently they started this migration when Go 1.9 was current. There have been significant improvements to Go's garbage collection since then, particularly in Go 1.12. I don't see any reason for Discord to go back, but we shouldn't conclude that other projects will see the same issue with current Go.
I'm not sure how much they would matter. For one thing, LRU caches are just fundamentally awful from a theoretical perspective for GCs to handle. Additionally, a better GC would just increase...
I'm not sure how much they would matter. For one thing, LRU caches are just fundamentally awful from a theoretical perspective for GCs to handle.
Additionally, a better GC would just increase performance. It wouldn't change the relationship between cache size and GC latency, just reduce it.
With newer versions of Go it would likely just be somewhat better, but it wouldn't change the decision making process. It would still be correct to initiate the rewrite at this moment.
Go's garbage collector is mostly concurrent (runs in the background), so for the most part it's a constant overhead, not long pauses. The part that's not concurrent is what causes latency, and...
Go's garbage collector is mostly concurrent (runs in the background), so for the most part it's a constant overhead, not long pauses. The part that's not concurrent is what causes latency, and they keep making that part shorter in new releases.
Also, if you're implementing a big cache and you can avoid having any pointers in the cache data structure, the garbage collector doesn't need to scan it at all.
Which is to say, the details matter and it's going to change depending on workload and which release you're running. Performance is the ultimate leaky abstraction, so thinking about it in broad theoretical terms doesn't get you very far, and performance tests often don't generalize (poor external validity). There's no substitute for measuring performance in production.
The blogpost talks about one performance critical service specifically, not the whole of Discord, but I found it interesting that Go's GC became a problem at that scale with no way to tune it other than rewriting a bunch of code with not much profit.
This is definitely the place where Go can improve the most. GC should be more tunable from the
go runandgo buildcommands instead of having to trick it into doing what you want in code.Based on discussion on Hacker News, apparently they started this migration when Go 1.9 was current. There have been significant improvements to Go's garbage collection since then, particularly in Go 1.12. I don't see any reason for Discord to go back, but we shouldn't conclude that other projects will see the same issue with current Go.
I'm not sure how much they would matter. For one thing, LRU caches are just fundamentally awful from a theoretical perspective for GCs to handle.
Additionally, a better GC would just increase performance. It wouldn't change the relationship between cache size and GC latency, just reduce it.
With newer versions of Go it would likely just be somewhat better, but it wouldn't change the decision making process. It would still be correct to initiate the rewrite at this moment.
Go's garbage collector is mostly concurrent (runs in the background), so for the most part it's a constant overhead, not long pauses. The part that's not concurrent is what causes latency, and they keep making that part shorter in new releases.
Also, if you're implementing a big cache and you can avoid having any pointers in the cache data structure, the garbage collector doesn't need to scan it at all.
Which is to say, the details matter and it's going to change depending on workload and which release you're running. Performance is the ultimate leaky abstraction, so thinking about it in broad theoretical terms doesn't get you very far, and performance tests often don't generalize (poor external validity). There's no substitute for measuring performance in production.