Factories in the real world have limits. They only have so many square feet, in which they can fit workers, machines, and resources. Our computers operate under the same principal that we are limited in our resources such as processor speed, RAM, network speed, etc. Part of programming is understanding how to work within these limitations.

Designing and programming applications that operate within the limits requires us to first to know, and then to understand a machines limitations. To know how fast an application will be processed we have to know how much time it will spend reading, writing, and processing.

Moore’s law has greatly alleviated this problem. We now have bigger, faster, and more efficient computers than we could have ever dreamed of, but that doesn’t mean we can ignore the bounds. We still need to understand which operations are expensive, reading data from a network location, compared to relatively cheap operations, such as incrementing an integer.

Even though modern computer hardware has greatly increased the resources we use, there are still areas where we must be vigilant. On example is, a web applications running on a server can easily be brought to their knees by a high user load. When developing web applications with a high usage these principals are not just helpful, they are required.

Once you understand the economics of the machine you can start to make intelligent trade offs for resources. One example is caching, a common strategy for reducing processing and data access by keeping a copy of commonly produced data in memory. These trade offs can have impacts, and create issues. Truly understanding the principals behind machine economies is very important.

Even though we should be aware of these principals, it is important to understand the real world trade off of time spent programming, and the need for software to ship. Many times we will release software that not terribly efficient on purpose. Maybe the time to develop was more pressing than performance, may be it is small web application that has a low usage. Whatever the reason we must accept that sometimes we must release software that is just good enough. That doesn’t mean we can be lazy as programmers, but it means that we should apply the principals of machine economics as we program, and know when we must hand tune our code.

Bookmark It

If optimization was easy there would be no slow applications. Slow performance rarely has a single cause. Depending on the number of causes, optimization is a difficult goal. Using a consistent, and defined process needs be a critical part of any optimization effort.

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%” -Donald Knuth

Optimization has a number of side effects, of which we must be aware. During optimization, many times, we must make trade offs. A classic optimization case is, trading processor heavy calculations in favor of using more RAM. Optimizing code can have the unintended effect of making code unreadable, and inflexible.

I mentioned before that Optimization is a difficult goal. I lied. The truth is optimization is not a goal, rather it is a process, also it is best handled as an iterative process. Using an iterative approach allows you to compare your results, and it gives you a better shot at isolating troubled areas. The worst approach you can have is to try tackle everything at once, because you will not be able to correlate the results to a specific change.

My personal process for optimization is pretty straightforward:

• Observe, and Measure
• Research
• Change
• Analyze
• Repeat (If Necessary)

Once you have a chosen something to optimize the first task is to observe and measure a metric, such as number of operations during a particular action. Attempt to do some research, as to why a particular section of code. Once you have your researched as much as you need to, use your best judgment, and make a change you think will have a positive effect. After making the change analyze whether it performed better than you original measurements, if it did you are on the right path, if not you have just eliminated a potential path.

If you are not happy with the results of a round of iteration. If you continue the process eventually you will notice that you are seeing diminished returns. A few items can be cherry picked, with a simple rewrite of this procedure. If optimizing the easiest items do not achieve your goals, then the difficult work will commence. The same procedure will be followed, but the success rate of the iterations will drop.

Optimization is one of the core group of tasks many developers will need to confront. A consistent, and methodical process will provide a stable foundation to any optimization strategy. Many times optimization goals may not be met, or will require a significant amount of effort. Serious optimization does happen, but we must realize that it is not something that just happens, it requires directed, and methodical effort.

Bookmark It