Artima.com has published Part VI of an interview with Martin Fowler in which he discusses balancing maintainability and efficiency, creating tunable software, the role of patterns, and the Agile Software Manifesto.
So you could make a performance optimization in one VM, and then bring in Hotspot, and it will actually slow Hotspot down. You've got to be very wary of that. Object pooling is a good example. A lot of people are very enamored with object pooling, yet half the time people are not measuring to that to find out whether object pooling is any good. Object pooling was very important in the early days of Java, because garbage collection wasn't terribly good. When you've got generational garbage collection, object pooling becomes a lot less effective, because short-lived objects can be collected very cheaply. It's the long-lived objects, such as ones you might pool, that are expensive to garbage collect.
So the rules keep changing. That's why you've got to be very careful to profile. If you think you can predict from the source code what the machine is doing, you've got no chance. When you're in a world of optimizing compilers and VMs, you have to profile, because the compilers and VMs are doing things that you can't even imagine. So don't predict, just measure.
> Anyway, the interviews are good, keep 'em coming.
Thanks. I'm planning to have at least one new interview installment each week from now on.
In fact, I am considering running two interview series at once next year, because each series takes about six weeks to complete. I want the interviews to be in-depth, which means either they are extremely long or I spread them out over many weeks. People don't actually tend to read long articles on the web, so that's why I chose to spread them out. But if I only run one interview at a time, I can only get about 8 of them out a year. If I run two of them at once, I can get about 16 out a year. I'd appreciate any opinions of whether two interview installments a week would be too much or just right.
In addition to interviews, I am planning on publishing a lot of articles and book content. I have two authors lined up for new columns, and I'm hoping to spend more time writing myself next year. And don't forget to submit your own great ideas for articles:
One thing that I'd like to add is the importance of getting performance requirements defined up-front, in some objective manner (ie System must support 100 transactions per second). Subject requirements (ie it's gotta be fast) won't due.
During performance tuning, tune until you reach this goal and then stop. Even if there are other areas that could be tuned, resist the urge to do it.
I, like many other engineers, certainly enjoy the process of tuning an application or system. It's a fun excercise, but we must realize that this excercise costs money and the return on it's investment could drop significantly if we tune for the hell of it.
Previous Topic
