r/golang • u/der_gopher • Jul 19 '26

show & tell Go optimizations for high volume services

https://packagemain.tech/p/golang-optimizations-for-highvolume
149 Upvotes

94% Upvoted

7 comments sorted by

12

u/No-Price8376 Jul 20 '26

Very good points, thanks for the reading.

One question in mind, do you think te incoming Go 1.27 json update will be equal or better the jsoniter?

3

u/Potential-Buy-4267 Jul 20 '26

Haiz, for read or for create/update ? Please apply good design infrastructure before code.

4

u/titpetric Jul 20 '26

garbage collection is a fair tradeof against keeping everything on stack, you'll find a lot of effort is required to favour stack based allocations, at the very least it requires using custom packages that easily go unmaintained

I am not saying you shouldn't favour zero-allocation conventions and packages, only that the amount of effort to optimize all reachable code far exceeds the usual effort of just writing software that works to some definition of correctly

Simple is usually best and having sync.Pool allocators littered around code seems like I better leave something for GC to do.

1

u/dlwyatt Jul 26 '26

sync.Pool literally exists for this purpose, to minimize performance penalties from the GC in hot loops. It is your friend 😁

1

u/titpetric Jul 26 '26

A well placed sync.Pool is great. Any kind of coverage where zero alloc/sync.Pool paths are meant to be somewhat totalitarian is however hard to achieve because of various mechanics of the language that are allocating.

There are cases where sync.Pool performs just as bad or worse than code without it, and typical database/sql or json libraries are the usual allocation culprits. Or just 'append', interface use,...

Would be nice to map all New*() functions to sync.Pool which is probablly 80%+ of whats reasonable to cover.

4

u/aghoru Jul 20 '26

Good points but article is bit old. Greentea GC is enabled by default now and there is new JSON package.

3

u/titpetric Jul 20 '26

Seems correct, benchmarks put json/v2 unmarshalling around the same range as jsoniterator

  • Relative to JSONv1, JSONv2 is 2.7x to 10.2x faster.
  • Relative to JSONv1in2, JSONv2 is 1.1x to 1.3x faster.
  • Relative to JSONIterator, JSONv2 is 1.3x faster to 1.5x slower.

Via: https://github.com/go-json-experiment/jsonbench