For a large codebase, this would be encapsulated and heavily commented, etc. It's something that you pull out when you need to make something "go to eleven" kind of thing.

Exactly. You could have some exhaustive unit tests as well, and after that there would be nothing to maintain.

Plenty of library functions are already going to be optimised in this type of way - just because they're not visible in your codebase doesn't mean they are not there.

So if your big codebase were profiled, and the 99th percentile case happened to spend 80% of its time in this function, you would still stick to the old function unwaveringly? Even if your system was latency sensitive, and your 99 percentile spikes were far from acceptable?

Sure, there are many cases where this is a premature optimization. This blog never said otherwise. But that doesn't mean there is never a time for optimization. And if profiling points at this, then this speedup can be valuable.

> rather have to maintain

Well, as long as it works, what difference does it make? As long as it's prefixed with a

// This compares the matching number of bytes

comment, you should never have to mess with it.

With a compiler or architecture change, I guess this could create awkward to handle performance regressions.

It's about use cases.

There was an old lady 6 about unoptimized behavior in VB6 and why is wasn't necessary to do so. I had to write a wrapper for it which was optimized in my code. Was it harder to read? Yes. Did it produce a significant performance improvement? Also yes.

Software development is about tradeoffs. Demoing one way to improve a simple function helps others trunk how they write code, and more importantly why they wrote specific code

I've worked with engineers that must read these blogs and try to out-clever everyone.

They succeed, and that's the problem.