So as I was saying in [0] and [1], there is no doubt that properly tuning the compiler for performance can make a significant real difference instead of wasting more money and risking an increase in costs just by throwing more servers at the problem.

Also, If you needed to re-architect the entire codebase to solve a performance issue, either you chose one of the most inefficient technologies / languages or the code itself was badly architected in the first place or both.

Before any architectural changes to the codebase first check if you can get performance gains from the compiler flags and measure it. That should be the industry standard practice for high quality efficient software.

We must learn from excellent SWEs teams such as DeepSeek which frankly embarrassed the entire AI industry due to their performance optimizations and savings in inference usage.

[0] https://news.ycombinator.com/item?id=43753443

[1] https://news.ycombinator.com/item?id=43753725

> -ldflags="-s -w": Strips debugging info, making the binary smaller

> I was honestly shocked when this simple change gave us an 8% speedup right off the bat.

Is that all they did to get 8% speedup? Could be a measurement error?

> Dave (our senior backend dev who’s been coding since before I was born) mumbled something like, “Wonder if we’re even using the Go compiler properly…” Most of us kinda ignored it at first — I mean, compiler optimizations? Really? That’s your big solution?

Young devs ignoring their seniors is a tale as old as time