This avoids the string concatenation altogether (the message format isn't necessarily more
efficient, but it is cleaner), and there are no method calls or allocation of the object array un-
less logging has been enabled.
Writing code in this way is still clean and easy to read; it took no more effort than writing the
original code. Well, OK, it required a few more keystrokes and an extra line of logic. But it
isn't the type of premature optimization that should be avoided; it's the kind of choice that
good coders learn to make. Don't let out-of-context dogma from pioneering heroes prevent
you from thinking about the code you are writing.
We'll see other examples of this throughout this topic, including in Chapter 9 , which dis-
cusses the performance of a benign-looking loop construct to process a Vector of objects.
Look Elsewhere: The Database Is Always the Bottleneck
If you are developing standalone Java applications that use no external resources, the per-
formance of that application is (mostly) all that matters. Once an external resource—a data-
base, for example—is added, then the performance of both programs is important. And in a
distributed environment, say with a Java EE application server, a load balancer, a database,
and a backend enterprise information system, the performance of the Java application server
may be the least of the performance issues.
This is not a topic about holistic system performance. In such an environment, a structured
approach must be taken toward all aspects of the system. CPU usage, I/O latencies, and
throughput of all parts of the system must be measured and analyzed; only then can it be de-
termined which component is causing the performance bottleneck. There are a number of ex-
cellent resources on that subject, and those approaches and tools are not really specific to
Java. I assume you've done that analysis and determined that it is the Java component of
your environment than needs to be improved.