Note: This blog is no longer active. Please visit Jeff's current blog instead. Unfortunately, any new comments entered cannot be retained or displayed. If you feel strongly about a blog entry, please contact us.
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.
February 2004 March 2004 May 2004 September 2004 October 2004 January 2005 February 2005 September 2005 October 2005 November 2005 December 2005 January 2006 February 2006 March 2006 June 2006 August 2006 January 2007 February 2007 March 2007 April 2007 September 2007 October 2007 November 2007 December 2007 January 2008