How to Avoid Performance Bugs

Suppose your application works but is just slow. Is that a bug? I suggest that if it is slow enough that your users will dislike your software, that’s a bug.

In a recent release of our application suite, five percent of our bugs were performance problems.  Two types were the most common:

  1. A perennial problem is excessive AngularJS $watches. These are AngularJS’s way of implementing an observer pattern. They can be very expensive, and AngularJS has a habit of setting up thousands of them before you know it, and where you wouldn’t expect it.
  2. We are saddled with supporting Internet Explorer 11, which is notoriously slow at anything related to DOM manipulation or memory management. For example, a <datalist> with a couple of thousand entries will work just fine in Chrome, but will bring Internet Explorer to its knees.

The longer a bug is allowed to live, the more expensive it is to kill. In both of these cases, the best way to find the bug early is for developers to use Internet Explorer 11 and large volumes of data during development. They don’t have to do this for the entire development of a feature, but from time to time they should check their code in these more challenging environments.

Internet Explorer is nobody’s favorite browser at this point in time, and it’s easier to create small volumes of test data than large, so it has been difficult for us to form this habit. That’s why these practices are on the checklist I’ll share at the end of this series. Until a developer can check these boxes, the code should not even be going to code review, much less QA or acceptance testing.

Your application may have other areas where performance is a frequent problem. Wherever they are, you can devise development practices that will catch problems early, and add those practices to a checklist.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.