The computing industry often sacrifices performance for convenience, complexity, or tight deadlines. I focused on making things faster by stripping out unnecessary layers, optimizing core processes, and prioritizing efficiency over feature creep. It’s amazing how much speed you can regain by simplifying instead of stacking. Performance isn’t a luxury—it’s foundational. The key is to treat it as a feature, not an afterthought.

>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.