Java Reference
In-Depth Information
to pay the costs inherent in separating a computational process into distinct abstracted layers
(such as queuing overhead, coordination overhead, and data copying).
However, when the monolithic system reaches its processing capacity, we could have a ser-
ious problem: it may be prohibitively difficult to significantly increase capacity. So we of-
ten accept the performance costs of longer service time or greater computing resources used
per unit of work so that our application can scale to handle greater load by adding more re-
sources.
Of the various aspects of performance, the “how much” aspects—scalability, throughput, and
capacity—are usually of greater concern for server applications than the “how fast” aspects.
(For interactive applications, latency tends to be more important, so that users need not wait
for indications of progress and wonder what is going on.) This chapter focuses primarily on
scalability rather than raw single-threaded performance.
11.1.2. Evaluating Performance Tradeoffs
Nearly all engineering decisions involve some form of tradeoff. Using thicker steel in a
bridge span may increase its capacity and safety, but also its construction cost. While soft-
ware engineering decisions don't usually involve tradeoffs between money and risk to human
life, we often have less information with which to make the right tradeoffs. For example, the
“quicksort” algorithm is highly efficient for large data sets, but the less sophisticated “bubble
sort” is actually more efficient for small data sets. If you are asked to implement an efficient
sort routine, you need to know something about the sizes of data sets it will have to pro-
cess, along with metrics that tell you whether you are trying to optimize average-case time,
worst-case time, or predictability. Unfortunately, that information is often not part of the re-
quirements given to the author of a library sort routine. This is one of the reasons why most
optimizations are premature:
they are often undertaken before a clear set of requirements is
available
.
Avoid premature optimization. First make it right, then make it fast—
if
it is not already fast
enough.
When making engineering decisions, sometimes you are trading one form of cost for another
(service time versus memory consumption); sometimes you are trading cost for safety. Safety
doesn't necessarily mean risk to human lives, as it did in the bridge example. Many perform-
ance optimizations come at the cost of readability or maintainability—the more “clever” or
nonobvious code is, the harder it is to understand and maintain. Sometimes optimizations
