Chapter 17. Addressing Performance

The Role of Performance in Design

Worrying about performance when you're first designing an application can be a stumbling block if you're not careful. Your first priority as a designer should be to produce a good object-oriented design. You want to build systems where responsibilities are allocated to reusable components that hide their implementations behind public interfaces. You want these components to provide a cohesive set of functionality while keeping the coupling between components to a minimum. You want each class that helps make up a component to encapsulate the data and methods needed for a related set of tasks and to do it in a way that results in granular classes that can be reused. And as if all that weren't enough, you want your classes to be built from relatively short methods that are easy to understand, test, and extend as new requirements are added. This is a nice list of goals, but nowhere in it does it mention performance. The problem is that performance optimization and good object-oriented design don't always go hand in hand. They can instead contradict each other. Of course you can't ignore performance in your designs or you'll face the risk of building a system that either can't meet the constraints of its target environment or runs so slowly that no one will use it. The trick then is to know when to be concerned about how well a system will perform. You don't want to minimize the importance of system responsiveness, but you don't want to let anticipated performance problems that might never materialize drive a design either.

The nonfunctional requirements for an application should contain specifications that tell you as a designer what the criteria for a system's performance are. This might include requirements for the maximum time a user should be expected to wait for a Web page to display or the maximum time that can be allocated to a transaction that ties up an external system. Without requirements such as these, describing how well a system performs is subjective . This opens the door to systems that either don't meet expectations or suffer from the opposite extreme with designs that are too heavily influenced by concerns about execution speed. When you know how a system needs to perform, it's easier to determine if the performance requirements pose a risk to building an acceptable application. The higher the risk, the earlier in the process it makes sense to worry about performance. The preferred approach from a strictly object-oriented point of view is to do a design, build the system (or pieces of it), isolate any performance problems, and then focus your efforts on alleviating the bottlenecks. If you're faced with performance requirements that pose a risk, then it makes sense to prototype parts of the system to make sure the architecture can support what's required. Otherwise, letting performance concerns creep into your design too early can lead to a less flexible system that's difficult to maintain and possibly not as portable to other platforms.

Performance optimizations made after a system has been implemented or partially prototyped usually are application-specific. If specific queries are too slow, changes to the database schema or how the database is accessed might be necessary. If a problem is traced to a section of code that takes too long to execute, optimizations that might include rewriting some of the code in a faster language can be pursued. It's usually the case that overall performance is driven by a small percentage of the code. When this is true, you can expect good results with this type of approach. When performance problems are more widespread, it's possible that the architecture selected for the application is inadequate or it's not being fully exploited. It's also possible for an architecture to be too heavyweight for a set of requirements. EJB offers a lot of benefits, but not every program needs the substance (and accompanying overhead) of an enterprise-strength distributed architecture backing it.

Application-specific tuning is important, but, by definition, it's specific to a particular system and difficult to address in general terms. Basically, you have to first find out why an application doesn't perform as well as it needs to and then look for alternative approaches in the problem spots. There are, however, some general guidelines for designing better performing systems from the ground up. You might think that this goes against what's been said so far about designing for maintainability first and then tuning for performance only when necessary. That advice is still true, but you also need to be conscious of the fact that building a system using a distributed architecture has known performance issues that have already been encountered and addressed by many other developers. Addressing these issues with techniques that affect your class implementations without impacting your overall architecture offers you a way to avoid later problems without sacrificing too much from a design standpoint. The intent of this chapter is to cover general performance guidelines consistent with this idea. Even if you don't want to address performance in your initial design, the topics covered here are a good place to start if you identify isolated problems after constructing an application.