Comment by vrnvu
4 days ago
My first thought: Controlling allocations and minding constraints... honestly, that's engineering stuff all services should care about. Not only "high-volume" services.
4 days ago
My first thought: Controlling allocations and minding constraints... honestly, that's engineering stuff all services should care about. Not only "high-volume" services.
I'm definitely in favor of not pessimizing code and assuming you can just hotspot optimize later, but I would say to avoid reusing objects and using sync.pool if it's really not necessary. Go doesn't provide any protections around this, so it does increase the chance of bugs, even if it's not too difficult to do right.
What are the options? Repeated allocations are a huge performance sink.
I mean, do it if it's worth it. But the parent seemed to imply everyone should be doing this kind of thing. Engineering is about tradeoffs, and sometimes the best tradeoff is to keep it simple.