Coding For Performance

Posted by:

Coding For Performance

Everybody hates it when they have to wait for an application to do something. Even when an application performs a task that the user knows will take several minutes to complete, the user still wants to see real-time progress of that task. A great example of this is downloading music to a portable player. Unless that progress bar is constantly moving, even if in only small increments, the user at least knows that something is happening (and even then, they still wish that it would run faster). It is incredibly frustrating when the progress bar stops moving, because the user has no idea if the application is still doing something and the user just needs to wait, or if the application crashed. Putting background tasks aside, when the user does something with an application, they expect it to see something happening, and they expect it respond quickly and perform especially under load.

The number one cause of poor performance is poor coding. Over the years, I have heard many developers say that they’ll get it to work first and then make it perform second. This, in my opinion, is the wrong way to develop applications. There are always at least two different ways (usually more) to write code that achieves the same exact result, but there are far fewer solutions that will perform and scale over time. Performance should always be considered when writing code at the time it is written, not as an afterthought. While this does not guarantee you the best performing application, it usually results in applications that perform better than most, especially when performance is always a consideration in every piece of code you write. Code that is adjusted for performance after it is written is much more difficult to do because poor coding practices become inherit in the architecture of the code. As a result, you will usually find hacks around the code to try and boost performance (because there isn’t enough of time or it is too difficult to re-write it correctly, which then makes the code harder to maintain), or results in entire sections of the code being re-written. In both cases, time could have been spent adding new features or functionality to the application, rather than trying to make the existing application work better.

Another thing that I hear from developers is that the amount of time that different code takes to run, whether you do it one way or another, is negligible. While two different algorithms may only differ by a few milliseconds, a few milliseconds can increase exponentially when an application is under load. The impact will depend on what the code is doing and what resources it is using. The reason for this is that applications run in environments with limited resources (e.g. memory, hard disk space, bandwidth, processing speed, etc.), and each type of resource used, when under load, will have various degrees of impact on performance. While it is true that computer resources are cheap, there are often times things that affect the resources you are using that are beyond your control. For example, many applications today require some sort of Internet connection. Regardless of how good your application is, if its a bandwidth hog, people are not going to enjoy using it during peak Internet times because your application will appear to slow down. The very basis of cloud computing is a “pay for what you need” model. Applications that perform better will not only cost less to run, but will result in happier users.

My advice: Always keep performance in mind when writing code. Ask yourself how well your code will perform, not only by itself, but within the application as a whole. Consider the components that you are using within your code and how they work, as well as what other components may be using your code. Learn about the components you are using, because how they work internally will affect how your application performs. Consider the technology you are using, because that may have an impact on how you choose to write your code. And, consider how often your code will execute, because code that is used more frequently will have a greater impact on the overall performance of an application. (And, make sure you document your decisions in your code so that people know why you wrote the code the way you did.) In the long run, always keeping performance in mind will usually lead to better performing applications.


About the Author

If music be the food of love, play on. I'm passionate about technology, music, food and family. Technology, because it's a part of everything; music, because there is nothing like a perfect harmony; food, because I love to eat (and sip wine); and family, because life has no meaning without it. I'm a software and technology geek who works with an amazing group of people, plays the piano, loves to cook, and has an amazing wife and daughter with a son on the way.

Add a Comment