[PaulKeeble]

Usually "optimisation" is something that happens once a slow part of the system has been identified. So you develop data and expose the problem with a profiler and fix a few things that seem to be holding it up and then find the next stage of bottlenecks. You keep doing this until you meet your performance goal or you can't improve it any further and determine a completely different approach is required.

Personally I prefer to recognise those components ahead of time and think about performance and do experiments to start from an architecture that has a better chance of succeeding in its performance goals from the outset. So I tend to agree with the article that its much more effective to optimise at the architecture than the individual components but its also much harder to do that once the thing is built and working already and the same is likely true for a lot of organisations as well. Once organisational culture has been set its hard to fix it.

[drewcoo]

> Usually "optimisation" is something that happens once a slow part of the system has been identified

I wonder if that's because speed is easy to measure. It's certainly not the only thing that can be optimized.

[ZoomerCretin]

Finding and fixing the one and only source of poor performance is a minority of optimizations. The more common case is a lot of suboptimal code creating poor performance.