3 ms·
It's not that the Go team's decisions are different; it's that they are worse for most applications. If you read the first part of the series, the author goes i
by pcwalton 7y ago
It's not that the Go team's decisions are different; it's that they are worse for most applications. If you read the first part of the series, the author goes into detail on this. The problem is essentially that the Go GC focuses entirely on latency at the expense of throughput, which is not the best choice in most cases.
- skybrian 7y agoWell, yes, he says that, but I'm not sure it's an objectively worse tradeoff? It seems like it depends on what you think "most apps" are like. It's not obvious to me that throughput is usually more important than latency, since latency is what the user sees and throughput has more to do with how many machines you need.
- pcwalton 7y ago> It's not obvious to me that throughput is usually more important than latency, since latency is what the user sees and throughput has more to do with how many machines you need. No, it's not true that "latency is what the user sees". Only for interactive applications is that true. In fact, given a choice between the two, I would generally choose throughput over latency. The Go compiler is an example of an application in which throughput matters 100% and latency matters 0%. Even with some semi-interactive tools like ripgrep, throughput matters much more than latency, because throughput determines how quickly the search finishes. Even for servers, throughput often matters more in ways beyond how many machines you need. Would you rather have a Web page that takes 10 ms to load with 1 in 10,000 loads taking 2 seconds, or a page that takes 200 ms across-the-board? I'd take the former. Remember that another name for throughput in this context is allocation performance, which makes it clear how important it is.