I enjoyed your detailed response, it adds value to this discussion, but I feel you missed the point of my comment. I am against blanket statements "reduce all

I enjoyed your detailed response, it adds value to this discussion, but I feel you missed the point of my comment. I am against blanket statements "reduce allocations to reduce GC pressure", which lead people wrong way: they compare libraries based on "allocs/op" from go bench, they trust rediculous (who allocates 8KB per iteration in tight loop??) microbenchmarks of sync.Pool like in the article above, hoping to resolve their GC problem. Spend considerabe amount of effort just to find that they barely moved a needle on GC times. If we generalize then my "avoid long-lived allocations" or yours "reduce allocation rate in terms of bytes" are much more useful in practice, than what this and many other articles preach.