alt Hacker NewsKnuth's warning about premature optimization is really about not increasing complexity based on guesswork without profiling the actual bottleneck. That's about overall architecture design. What's happening here (in this blog post) is locally for the sake of learning, and further, for intellectual fun - I think it's completely justified. Usually, the 'don't do premature optimization' quote gets misused as an excuse to avoid careful design, but setting that aside, learning within these kinds of constraints and eventually producing something. that's not premature optimization in my view.
Looking at this code, they saved one AND instruction and reduced a pipeline stall, but it seems like it would be harder for a future maintainer to understand, because not_received feels a bit less readable. I always think code that's easy for the computer to read and code that's easy for humans to understand are different things.
After writing my comment, I realized it came across as overly critical. But actually, I think this work is completely justified and beautiful. Honestly, it's at a level I couldn't achieve myself. I respect it.
Replies
Is this about premature optimisation or just good architecture?
The number of data formats I see that miss obvious things like alignment etc. it isn't something you can easily change later if it becomes widely used.
To me this post represents the minimum you should be thinking about when designing any kind of data structure/format.
The only time where I would say it strays into premature is inverting the received flag, but only because you're optimising it for a particular processor and in a way that isn't particularly obvious. The inversion can easily be hidden behind a function call.
Premature optimization is that occasional dessert we serve ourselves because it tastes so good.
That said, I agree with you that the maxim is often used to justify poor planning or absence of planning. Premature pessimization is bad too.
We don't have the bandwidth to test every micro-decision. That's what the learning of domain specific principles are for. Then some choices you reason through, some you test and when confronted with a perf problem, test those reasoning based choices that benchmarks point fingers at.