>Performance isn’t a luxury—it’s foundational.

Reasons to always try to be nearly optimal on performance from the start, that I rarely saw stated:

1) What you can specify depends on what can be done, and to know what can be done you need to have tried your best. In particular, it allows to see early whether or not performance expectations are reallistic.

2) It's more difficult or impossible to upgrade performance later if it requires to break an API. It causes a development process in O(n^2) in number of layers, instead of O(n).

3) Better lower level performance makes higher level code and architecture simpler, as you can just brute force in more places for a same overall performance.

New products or features are of an acceptable performance only, sometimes not even that. Additional work on performance tuning is often followed up in a later version. It's really about priorities that have to be decided, and deadlines usually win.

Those that prioritize performance upfront can find all that work thrown out if the design needs to change for some reason.

But I think that performance by design upfront should be done where possible. This is where experience helps a ton.

I agree and I think there's a market for faster computers!