I am giving a talk in about a week at Pace University on improving performance of applications (where I’m using the term “application” to mean anything that interacts with a user – a program running on an iPhone or Windows computer, a web site, etc.). To help prepare for that talk, I thought I would write some of my thoughts on performance in this blog as a way to crystalize my thinking and organize my thoughts.

Why is performance important and why is it so hard

I think we all understand inherently why performance is important. We always want the program we’re using to run faster or get annoyed when the web page we are loading takes too long to come up.

Performance is hard because it takes time just like any other feature (one of my former managers would say “Performance is a feature”). I love this quote from Blaise Pascal because I think it applies to lots of things, but it’s particularly relevant to performance – “I would have written a shorter letter, but I did not have the time.” Developers could say “I would have written a faster application, but I did not have the time.” Speedy code is also hard because anyone who’s not working on making a faster application is, almost by definition, working on slowing the application down. They are writing more code and adding more features, which will take more CPU cycles. That slows things down. If you add a video to your website’s front page, you will slow down the loading of that page.

Tracking Performance

Since, in general, we all have limited time and resources for our projects, we must decide what areas of our program need to be worked on. The best way to do this is identify the user scenarios you care about - loading your website’s front page, checking out of a store, searching for a document by keyword - and see how long those take for your standard user. Which means you need to understand what device(s) your users are using and how they access your application. If you have a web application and a large number of your users are using a cable modem, it’s important that you run your tests with a similar connection and not connecting to your server with a 100GB Ethernet connection. Similarly, you can’t just measure the time it takes your web page to be generated on the server, you must take into account how long it takes the page to come up in your users’ browsers (which may include downloading 100 image files).

Once you see how long those scenarios take, you can decide which need work and which are already fast enough. Next time I’ll talk about ways to figure out where you are spending time and in subsequent articles I’ll discuss different ways to make your programs faster. But it’s important to keep testing your scenarios even if you feel the performance is acceptable today. Remember, everyone is working to slow things down and eventually you may need to work on an area that was satisfactory earlier.