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?
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.
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.
Huh? He had ALREADY written his library before he started optimizing.
He even says that the profiler didn't show much, because he had all parsing code inside one big function.
And he never said he _did_ optimize before.
Which kinda defeats the complain in the parent comment that he advocates optimize as you program.