How can I be quicker at resolving application performance problems [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

While I subscribe to and usually work in agile workplaces and I believe have reasonable standards, I often find performance problems difficult in the 'heat of battle', and may put off or not get started on as quickly as standard features.

Despite building on general performance knowledge for some time, I'd like to know what I can do to start fixing and arrive at performance related solutions sooner.

Answer 1

Your overall strategy during initial development should be to understand algorithms and data structures well enough to avoid writing code that is going to perform poorly by design.

For example, a triply nested loop with 100 iterations in each level may seem benign, but that's 1 million total iterations, and if anything is happening in that inner loop that takes any significant amount of time, then there's going to be a performance problem.

1. Choose your data structures wisely. If you need O(n log n) lookup, then an ordinary linked list isn't going to cut it.

2. Always measure first. Software developers are notoriously bad at telling how well code is going to perform just by looking at it.

3. Only optimize when you're going to get a significant gain in performance. Where this happens isn't always going to be obvious.

4. Whenever possible, optimize later. But don't fail to take advantage of those early design decisions that will insure your code performs adequately.

Further Reading
Back to Basics, where Joel Spolsky describes "Schlemiel the Painter Algorithm."

Answer 2

Stop going rogue. You're making more work for yourself, and you're actually putting your job at risk.

Don't work on performance "problems" that aren't recognized problems. And as a corollary, the business will grant you time during the course of your regular work to address recognized performance problems.

• If you believe an application's or feature's current performance isn't sufficient, is impacting other systems, or is a huge factor in high hardware or hosting costs, log it as a bug/request and let the stakeholders and product owner decide when/if you should spend time on it.
• If there's a serious performance problem in the scope of a currently assigned task/story that would prevent it from being functional, it's not necessarily a "performance" problem at that point; it's a "the feature isn't usable yet" problem. Do what needs to be done to finish the feature using "best practices."

Anything outside those two reasons is extracurricular. It needs to be done on your time, and you ought to be really darn sure your optimizations don't introduce any bugs.

But, it's really just best to avoid doing work the company doesn't explicitly approve ... lest you have to explain how you were "just trying to learn some stuff" Friday after hours and accidentally lost a bunch of customer data or something.