I’m always amused at the number of posts I see in Java forums about various performance concerns. Yesterday I read a sequence of anxious messages discussing whether Java’s import pkg.* performs worse than importing explicit classes. Once people were informed that it makes no difference at runtime, the concern moved to compile time.
Java compilation is slow, but it’s not that slow, and it’s also not C++, where concern over such minute detail can be rewarded handsomely. I think we’re talking close to picoseconds here. Someone did manage to run a time test and found a difference that equated to probably one minute over the course of a development year.
I find it odd that people are willing to waste hours debating this nonsense. Worse, they’re willing to sacrifice far more hours by sacrificing readability for execution efficiency.
I figure the anxiety over performance is due to two things: one, Java is one of the slower compiled languages out there (scripting languages such as Python typically fare much worse). Two, it’s something you can quantify easily.
With respect to the first concern, if you have that much angst over performance, perhaps you shouldn’t be programming in Java. Honestly, it’s not *that* bad, and plenty of systems execute with high performance while ignoring some of the minute optimizations that Java affords (for example, making all possible methods final). And usually, the concerns are misdirected. Some people even worry about performance when there are no known performance issues. But all it takes is a profiler (such as JProbe or OptimizeIt) and a bit of education to get the seance aspect out of performance optimization.
It’s the quantification that’s most alluring, however. Geeks like to speak numbers, or more importantly, they like to rank things. “Star Trek is better than Star Wars,” and “this construct executes faster than that.” Quantifying good programming style, however, isn’t possible. It’s subjective and debatable, so it doesn’t provide such an easy answer.
Get over it. Code for cost. The cost is in maintenance, and usually not in degraded performance. That means coming up with an optimal design–one where you can easily make performance tweaks if and only if you find performance problems. A bad design with bad performance will cost far more to fix than a good design with bad performance.
Not to say that you should ignore performance entirely, either. But right now my major concerns over performance aren’t about the production system’s performance. They instead are about the performance of my unit tests–something that directly ties to the cost of maintenance.
