Java Performance Tuning Course
Chania Crete, May 17-20, 2010
Sun Extreme Learning EXL-2025
Houston, December 1-4,2009
New York, December 8-11, 2009
Washington DC, January 5-8, 2010
San Francisco, January 11-14
Anti-if
My RSS Feeds
The Ultimate Premature Optimization
posted Monday, 22 January 2007
One of the things that I find surprise people who take my performance tuning course or talk to me about performance is my stance on premature optimizations. It is my opinion that taking extra ordinary steps to optimize when you don't know or are only guessing that you may have a performance problem is more often than not a waste of time. For example, I may over-stress the concept of DRY. But from my perspective, this is a design principle that not only encourages good structure, it make the identification and repair of performance problems easier. Yet people will continue to ignore good reason and take extra ordinary measures because they believe that may have a performance problem.
The ultimate premature optimization that I've run into a number of occasions is in choice of language. Yup thats right, people will choose C++ over Java because they believe that the runtime performance of C++ is better than Java. There is no doubt that there are conditions under which this is true and there is no doubt that this has been true in the past. But remember my definition of premature optimization is to take "extra ordinary measures" to solve a problem that you may or may not have.
For example, there is a local firm that has setup services that works with telemetry data from your car. They choose C++ to do all of their work. No problem so far. The reason for C++? Even though they know that development of the system will be cheaper in Java, there are concerns that certain critical aspects of the application will not perform. This is a fair enough concern so I conducted an impromptu mini version of my "Architectural Review for Performance" engagement. After a short time it became very apparent that they could not identify *any* point in the architecture where they felt performance was going to be so critical or inhibited by Java.
To make the story stranger, they recognized that they could build their proto-types much quicker in Java and thus more quickly discover what they really needed to know, was the system going to meet the *real* requirements of their customers. Now all of this is not to say that Java was the best choice for deployment. I did a little research in the space and quickly found a competitor to this local company.
The competitor had written a C based tiny HTTP server that sat in a chip in the engine of the car. Yet this company (sorry I no longer have a link to it) was being mentioned by James Gosling as an example of how Java was working in the automotive space. Turns out the company chose Java to do all of their prototyping work and from this generated the C implementation. Their assertion was that by using Java they could more quickly identify real issues and then use that knowledge to more quickly produce the working solution. For the record, C was needed because the chip didn't support Java and they were only allowed a very small amount of RAM.
Just last week I ran into a number of development teams that are using C++ simply because Java is to slow. Yet when I explore their performance requirements I rarely find any justification for that position. That said, you can't really argue against a development team that after sound analysis has decided that C++ is best for them. However to make that choice strictly on runtime performance is most likely a premature optimization or someone spreading FUD to protect a position. With the rise of distributed systems there are so many sources of poor performance that go way beyond the language.
The ultimate premature optimization that I've run into a number of occasions is in choice of language. Yup thats right, people will choose C++ over Java because they believe that the runtime performance of C++ is better than Java. There is no doubt that there are conditions under which this is true and there is no doubt that this has been true in the past. But remember my definition of premature optimization is to take "extra ordinary measures" to solve a problem that you may or may not have.
For example, there is a local firm that has setup services that works with telemetry data from your car. They choose C++ to do all of their work. No problem so far. The reason for C++? Even though they know that development of the system will be cheaper in Java, there are concerns that certain critical aspects of the application will not perform. This is a fair enough concern so I conducted an impromptu mini version of my "Architectural Review for Performance" engagement. After a short time it became very apparent that they could not identify *any* point in the architecture where they felt performance was going to be so critical or inhibited by Java.
To make the story stranger, they recognized that they could build their proto-types much quicker in Java and thus more quickly discover what they really needed to know, was the system going to meet the *real* requirements of their customers. Now all of this is not to say that Java was the best choice for deployment. I did a little research in the space and quickly found a competitor to this local company.
The competitor had written a C based tiny HTTP server that sat in a chip in the engine of the car. Yet this company (sorry I no longer have a link to it) was being mentioned by James Gosling as an example of how Java was working in the automotive space. Turns out the company chose Java to do all of their prototyping work and from this generated the C implementation. Their assertion was that by using Java they could more quickly identify real issues and then use that knowledge to more quickly produce the working solution. For the record, C was needed because the chip didn't support Java and they were only allowed a very small amount of RAM.
Just last week I ran into a number of development teams that are using C++ simply because Java is to slow. Yet when I explore their performance requirements I rarely find any justification for that position. That said, you can't really argue against a development team that after sound analysis has decided that C++ is best for them. However to make that choice strictly on runtime performance is most likely a premature optimization or someone spreading FUD to protect a position. With the rise of distributed systems there are so many sources of poor performance that go way beyond the language.
comments