A lot of my poor opinion on developer opinions dates back to a couple projects where Product and Marketing were begging us for substantial performance improvements and the teams pushed back saying this was as fast as you could expect. I got 2x in the first six months on both projects, and delivered 25% per quarter on one for almost 2 years (that maths to around 8x) before I started to scrape the bottom of my barrel.

It’s predominantly a way to shut down thinking, which is why it’s so often misquoted. Knuth’s version is more nuanced. Theirs is not at all.

As a compromise I got really good at doing optimizations that also improved readability. Things like hoisting and better variable naming combined together can be mistaken for just code cleanup.

I also discovered that keyhole optimizations are more palatable. Which is to say, move the slow bit yo a separate function with a single responsibility. Then do the optimization in a separate commit. Then the other devs don’t have to look at your changes and if they turn out to have a bug, we can always revert the change later. They almost never do, but having the option seems to grease the wheels.

That’s just pattern matching. Most people don’t do this level of prep so they assume you didn’t either. There’s usually no ill intent, and people are maybe a little embarrassed when you point it out, but if you are tactful it’s fine.

> objectively

I see what you did there

Processors I mostly write firmware for have little cache at all.

I think cache friendly code also tends to be reason about friendly and debugger friendly. None of that is remotely premature optimization.

Before AI, nobody has been responsible for more psychic damage against software developers than Bob Martin.

There's not enough context for me (or other commenters) to really evaluate this, but every change has risk, and some projects aren't in a position to be accepting that risk.

A "real performance bottleneck that I observed during testing" is a little bit unclear whether it occurred outside of test conditions, or whether speeding up that particular bit improves anything anyone cares about.

> Technology is sadly increasingly homogenising around Unreal Engine 5

I kinda get the commodification of games engines and Unreal. I am sure a lot of us saw the gaming revolution unfold, watching gaming companies one-up each other in graphics and interactivity. But once you get to the point of UE5, Unity, or Godot there is little need or value to make a game engine from scratch anymore.

Don't get me wrong, if you want to write an engine, go for it. But if you just want to make a game then an existing engine is good enough.

Not unique to gamedev; during the boom at the turn of the millennium the bar to entry to programming was dropped on the floor to fill demand.

The vast majority of programmers today don't even understand the basics of how-computer-work - not just microarchitecural considerations but even how to interface with the kernel efficiently / understand the performance considerations of their target platform.

Ask your average programmer how to say, simply perform I/O efficiently as possible on NT given some workload characteristics. One needs to first understand this before they can begin making concessions in favour of other demands (abstraction, flexibility, ect) and very few programmers can even get beyond the starting line.

Heap allocations aren't really the culprit of the waste that the root comment is talking about. Indirection in general is, and passing around an allocator doesn't guard you against that. Virtual dispatch occurs even for objects on the stack.

Looking at the specs: 32 KiB of L1, 256 KiB of L2, in-order and partial dual-issue.

That's the least forgiving kind of chip when it comes to performance: fast enough to outpace main memory by two orders of magnitude, yet the slightest speed bump (branch misprediction, cache miss) stalls it without any ability to reorder around it.

What is a cache friendly version of linked lists?