Tips for Integrating Optimization Into the Development Cycle
Testing and optimizing are often just tacked on at the end of the development process. But mixed in judiciously, they can pay major dividends.
by Chris Preimesberger

Posted September 29, 2003

Enterprise application developers often are not optimistic about having to optimize their work while it's being built. In fact, they often would prefer not to think about optimization at all—until the build is as final as it can be.

It's easy to see why. Stopping to test and fine-tune a work in progress is often scowled upon as a foolish waste of time, energy, and company resources, especially in today's Rapid Application Development (RAD) and eXtreme Programming (XP) development worlds. After all, why not just do the build, then test and fine-tune to your heart's content in the final stages of the cycle?

That's a valid argument, but there are also strong opinions against it. In getting the work done as efficiently as possible, IT managers know quite well that every added step in the software development cycle makes an impact, however large or small, on the bottom line of a company's P&L statement each quarter. Too much time spent on unit testing and optimization while in the process can put a significant dent in overhead cost and developer health. However, just the right amount of testing keeps the project flowing smoothly and is more likely to produce an optimum product; the correct balance is the nirvana IT managers crave.

Then again, the customer might have different priorities.

"I find that almost all customers don't even think or ask about performance until right at the end (of the project)," said Matt Jacobsen, a longtime enterprise Java developer currently with Aircraft Technical Publishers in Brisbane, California "All they want to make sure of is that the application works. They usually don't care about whether it works fast, which is what I consider the main criteria of performance."

Point of Agreement: Unit Testing Is a Must
Even XP programmers (who like to leave all testing until the end) can generally agree that some unit testing is beneficial in the course of the cycle—gathering requirements, architecture, programming, testing and QA, production, and shipping. Otherwise, how do you really know if a component is going to behave the way you want? And how do you know how it will perform under heavy usage—say, 10,000 calls a minute?

You don't want to have to go back deep into the code to fix a little command button just because it's acting quirky. Doing something over is the last thing a developer wants to do.

Obviously, developers can't rely solely on compilers and code generators for optimizing their applications at the end of the process. They also can't depend on the latest processors to add much speed, even though they are always being improved, to run their apps at maximum efficiency. Finally, the demands for performance on differing hardware devices often requires customized optimization.

Guy Rish, an experienced .NET and Java enterprise developer based in Louisville, Kentucky, who created his own .NET runtime extension for ColdFusion called Black Knight, had three things to say about his own methodology.

"Unit test, unit test, unit test," he said. "Generally, write it first, optimize last. Most clients are interested in reliable functionality, not speed.

"For the average business application, speed is seldom really a factor, and most users would much rather have an app that doesn't blow up on them than one that is really fast and explodes," he said. "Unit testing all the time reduces bugs, and (in general) will give the developer acceptable speed. Waiting until the app is solidly written and (relatively) bug free to tweak the code in special ways will yield better results and introduce fewer bugs."

Don't Wait for a Problem to do a Tune-up
Both Jacobsen and Rish said it is good advice to test and solve code and component problems at incremental points, before errors and bottlenecks in the code build upon themselves and cause even more issues.

Performance optimization tools can also be used several times in the development process, but not to the point of throwing the schedule out of whack. This cuts off most problems before they can become buried in the code and more difficult to find and fix later.

Time to market and overall cost of the project can actually be decreased by early identification of problems and potential problems.

"String unit testing—not so much for performance but for usability—is essential, all through the process," Jacobsen said. "You should test each bit of code you write each day, to make sure it compiles correctly and does what it is supposed to. If you do a little at a time, you'll save yourself a lot of time and trouble later."

Kyle Gabhart, a Forth Worth, Texas, Java expert who's heading up the reconstruction of Pier One Imports' corporate sales system from a legacy mainframe system to a new one in J2EE, says he has his group compile and test code each day at least once—sometimes more often.

"We're building a real-time system that will link up our backend services with a point-of-sale front end," he said. "We have to test each bit of code as we go … there's no build, build, build, and compile on our agenda. Everything has to be solid before we move on to the next piece."

Five Key Testing/Optimization Areas
It's important to know that you can test and/or tune five areas of the application to take advantage of the target server's capacity for concurrency. All five areas should be tested every time optimization occurs.

• Input/output. Tuning I/O for scalability means minimizing latency and optimizing throughput. This usually means sending as few large chunks of data as possible to maximize bandwidth, and to amortize the latency cost.
• Multi-threading and hyper-threading the scheduling apparatus. Operating systems schedule different threads or processes onto different processors. Applications that use multi-threading can also take advantage of multiple processors to enhance concurrency. Hyper-Threading Technology, which allows multiple threads to run on a single physical processor, has already appeared in the Intel Xeon processor. Intel has announced that in the future, Intel processors for the desktop will also incorporate this technology.
• Critical sections. Multi-threaded applications need synchronization points. These are called "critical sections"—places in the application where only one thread can have access at a time. A lock usually protects critical sections, and access to the lock is required to execute this part of the code. Access is then serialized. Since any serialization point can be a performance limitation, eliminating contention and waits at critical sections is key to good application scalability.
• Data access and structures. Efficient data access is important for scalability, especially involving data drivers, which are the key targets here. If a processor has to wait for data, computing efficiency and scalability always suffer.
• Memory allocation and management. The ability to hide latency associated with memory access and memory management is one of the key methods for enhancing concurrency.

Testing/Optimizing Reused Code
If you know you'll be reusing code, the first step in optimizing is to run this code "as is" and see how it works with your target processor, if it works at all. All notes taken here should begin your optimization record. Next, recompile the reused code, and again test it on the target processor. Then test it for secondary processors, if necessary.

This is where you select the correct development platform for the project, whether it's Java, .NET, C++, or whatever. Strategic thinking definitely comes into play here. Making sure your framework is optimized far ahead of time for best results is probably the most important strategic decision you will make.

Optimizing during programming and final overall app testing are the most important (and obvious) times to upgrade and speed-up code. You may want to build in at least a twice-weekly window for optimization. If you schedule it into the routine, perhaps near the end of the day at a predetermined point, it becomes an organic part of the process and makes QA that much more effective.

Thanks to Sunita P. Shenoy, Technical Marketing Manager, Intel Software Development Products, for her assistance in compiling the information for this article. Some information was gathered and updated from tutorials on the Optimization page on the Intel Developer Services site.

About the Author
Chris Preimesberger is an IT writer/researcher based in the San Francisco Bay Area.