> It's all about the metrics. Profilers are your friend. In my experience, profilers are not used nearly enough. They also tend to be used when systems are at

> It's all about the metrics. Profilers are your friend. In my experience, profilers are not used nearly enough. They also tend to be used when systems are at or near crisis already. It's way more valuable to have profilers run at on every build (or at least every deployment) to see if there's regressions. Having performance metrics in production to continually track key metrics is critical. All software is built with assumptions that impact performance and all of a sudden those can be invalidated. There's a lot of O(N^2) code that's just fine right up until it explodes. Some examples I've run across: - A query API that could contain metadata saying "throw away this result and re-query with these values instead" that worked great for years because it only impacted a single-digit percentage of queries. One day the users decided to really start using this feature, and found that the impact of executing a query that took 100ms and running another 100ms query was way worse than doubling the average. - A system where you could configure plugins to make "pretty" URLs by running a list of regular expressions. Again, this worked great for years until both the number of URLs and the number of plugins increased and the 25% of the page generation time was spent running regular expressions.