I write code primarily to analyze data from my experiments, and I do it primarily in Python. I have been told (and have read) repeatedly, that optimizing is to be done right at the end and only to optimize the inner most loop etc.
From my reading, this guy is advocating the exact opposte: optimize as you code. It sounds sensible, but what to other people who have to optimize for a living have to say?
I think the difference here is that the problem is completely understood from the start: there's a MySQL protocol (which the author has already implemented in the past) and his project needs to be able to handle that exact protocol as quickly as possible.
This. Also the applicability of the optimization rule depends a lot on the context. It is typically stated for a complete project. Writing a library is different from that.
Depending on the kind of library you write, it could be that it is called in a hot inner loop of an outer project. So yes in that case it would make fully sense to optimize the heck out of the complete library (like e.g. a mysql client).
Another point is to see the reasoning behind the optimization rule. Optimization always is associated with cost (cost of programming, additionaly complexity in the code, maintance). This cost has to be recovered from the effects of the optimization. As the number of users for a piece of code grows, the benefit of optimization rises, but the costs should be more constant. Thus at scale it also makes sense to look a smaller optimization potentials.
But this does probably apply to not even 1% of the typical projects.
It depends on what your primary goal is. If you want to write a program to do X, then you write a program to do X, and worry about performance later.
If you want to write a really fast parser, then you start out by thinking about the best optimizations that will give you a very fast parser.
To be fair, the author of this did write his library first without thinking too much about optimization, and then came back to make it faster. Unfortunately that sometimes means throwing away large pieces of code that just can't be made fast.
As with anything else, it's a balance. I think everyone should be writing code with performance in mind at least a bit. Just how much is dependent on the problem you're trying to solve and what your goals are.
From my reading, this guy is advocating the exact opposte: optimize as you code. It sounds sensible, but what to other people who have to optimize for a living have to say?