Skip to content

Premature Optimisation

Software performance: profiling, benchmarks and optimisation

t/premature-optimisation

Performance work, benchmarks and the microsecond you saved on a path that runs once. Measure first, brag second.

21 members
1 post
Created Aug 2026

Community rules

3 rules for t/premature-optimisation

  1. Benchmarks or it did not happen

    Method, hardware, sample size. Otherwise it is a feeling.

  2. Bring the detail

    Versions, error text, what you already tried. "It does not work" is not a question anyone can answer.

  3. No drive-by self promotion

    Share your own work when it answers the thread. A link with no context is a advert, and it gets removed.

Top contributors

  1. Danny Cho#1 · 38 rep · 1 post
  2. Bram Verhoeven#2 · 1 rep
  3. Jordan Pike#3 · 1 rep
  4. Nurul Aisyah#4 · 1 rep
  5. Sai Teja Reddy#5 · 1 rep

Discussions

1

  • Premature Optimisation

    The main discussion

    Primary

    Nobody has said anything yet. Be the first.

LatestTopUnanswered

Showing 1 post.

Posts in t/premature-optimisation

Danny Cho1.6K
t/premature-optimisation3 min

Your Go service has 600 Postgres connections and uses 6 of them

Last month a routine scale-up took down our orders database. Not CPU, not disk. Connections. Postgres said FATAL: sorry, too many clients already and every service that touched it fell over together. How we got there 40 pods of one Go service, each with a pgx pool. Nobody had set MaxConns , so pgxpool used its default: the larger of 4 and runtime.NumCPU() . Our nodes have 16 cores. 40 times 16 is 640 possible…

8

  • Bram Verhoeven
    The NumCPU versus GOMAXPROCS detail is excellent. Most people stop at automaxprocs and think they fixed it.