|
|
|
|
Back to newsletter 024 contents
For years, Heinz has entertained us, made us think hard, and often surprised us in his popular newsletter "The Java Specialists Newsletter". This month, JavaPerformanceTuning.com asked Heinz a few questions:
Q. Can you tell us a bit about yourself and what you do?
Sure. I was born and raised in Cape Town, South Africa. My parents are of German origin, so I grew up speaking mainly German, even though English is common in Cape Town. South Africa has 11 offical languages, but German is not one of them [;-)]
When I was in junior school, I started playing around with the ZX Spectrum, and my love for programming (not computers - I hate computers with a passion) developed back then. At the time when I finished school in 1989, our country was in a lot of turmoil, with compulsory military service for "white" males. You could delay military service by attending university, so I enrolled for a BS in Computer Science at the University of Cape Town. Seven years later, at the tender age of 25, I emerged with a PhD in Computer Science, having skipped the MS. By the time I finished, South Africa was already a real democracy and so I managed to avoid conscription altogether.
My doctorate title was: "Analytical performance evaluation of concurrent communicating systems using SDL and Stochastic Petri Nets". You see, even then I already had a keen interest in how well computer systems perform, although my thesis was of more theoretical nature and not that useful for day-to-day work.
For many years, my wife and I were considering leaving South Africa for greener pastures in Europe. 9/11 and the .com fallout have made it clear that the pastures are greener down here. There is a lot of Java technology being used in Cape Town. Besides all that, Cape Town has been voted as the #5 place to visit for a holiday before you die. A Russian, who settled in South Africa, once said: South Africa is THE BEST place in the world to live, because, if you want to go on holiday, you are already here!
I have my own software development company ( http://www.javaspecialists.co.za) where we write contract software, consult and hold courses on Java and Design Patterns. Due to various recent circumstances, I am also director of a drinking straw factory. Diversify! - they said.
Q. You make it sound like South Africa I.T. hasn't been affected by the current I.T. recession in many other countries. Is that how you see it?
I would rather say that South Africa was not as strongly influenced by the ridiculous .COM boom that hit the world. Salaries were at a reasonable level (for the employers) during the good years in other countries. As a result, a lot of good people left the country to go to England and USA. However, now that the good times are over, quite a few of them are coming back to this beautiful country.
It is difficult for foreigners to come to South Africa and live here due to restrictive labour laws (which might be changing for IT jobs). The locals therefore have very little competition on the job market. I am not saying that there are a lot of golden opportunities, but you have to take salaries in relation to how much things cost here. I bought my first 2 bedroom house about 5 years ago for US$ 15 000. It would be worth more now due to house prices climbing, but for US$ 50 000 you would get a very nice place. Fresh food is also very cheap, as is petrol. All-in-all it is probably the best place on earth to live [:-)]
Q. How did you get started writing the Java Specialists newsletter?
One of the things I love doing is exchanging interesting programming ideas with my friends. Back in 2000, one of my friends kept on bugging me to start writing a book, called "Java Argot, Things your Dad never told you". On one of my many consulting trips to Germany, I started writing down topics for such a book. I started writing with the objective of creating a book, and started to really enjoy just writing newsletters. So much so, that I now have no desire to ever go through the headache of writing a real book. My father's cousin is a famous South African writer, so I suppose it is somewhere in my genes.
Once I started writing, I discovered the amazing marketing potential that is locked up in producing an original piece of writing. Not to mention the fun when I get comments from my readers telling me that they are enjoying what I'm writing, and asking me what food they should eat in order to think like me. BTW, if you know of anyone who would like a course on Design Patterns, here is my brochure: http://www.javaspecialists.co.za/designpatterns/brochure.html Ok, that was a joke. I'll try not to be too much of a used-course salesman [;-)]
My first "The Java Specialists' Newsletter" was sent on the 30th of November 2000 to 75 friends, colleagues and former students. The newsletter is now read by over 5000 people in 89 countries (http://www.javaspecialists.co.za/countries.html). However, what really distinguishes this newsletter is the readership. I have some of the top Java & OO people on my newsletter subscriber list: Bruce Eckel, John Vlissides, Cay Horstmann, Jack Shirazi, Craig Larman, William Grosso, Erik Hatcher. The list just goes on and on.
Q. What do you consider to be the biggest Java performance issue currently?
That is a really difficult question to answer. My focus during the last five years has been J2SE and its supporting role in J2EE. However, Java is so huge, and within every part of it (JSP, Servlets, EJB, J2ME, JMF) you can find serious performance problems if you look for specific situations.
I personally do not think that performance is really a problem in Java. I think the real problem is one of perception. Java has received plenty of bad press from C++ and Delphi programmers about its supposed performance problems. I remember a time not too long ago when "serious" applications were not written in C++, because that was so much slower than C. That is why I think that the performance "problem" is not a real problem, it is an illusion that people have held on to.
If you want to write an application in Java, you could use Swing. Swing is sluggish and slow. It is improving, but it is still not as snappy as native user interfaces. However, if you need a snappy user interface, what is stopping you from using SWT?
Another topic that people like to focus on with Java is that you cannot easily create an executable under Windows. Again, in real projects, I have never found that to be a problem in any way.
So, the biggest issue to me is that people have this IMPRESSION that Java is SLOW.
Q. Do you know of any requirements that potentially affect performance significantly enough that you find yourself altering designs to handle them?
Yes, remote method invocations. Whilst a nice idea, it can bring any application to its knees if overdone. The first thing you would look at is the architecture, and whether it fits the problem. The second thing you do is look at the design of how that architecture was implemented. For J2EE, you would look at using Session Facades, Value Objects, etc. to make J2EE run fast.
Q. What are the most common performance related mistakes that you have seen projects make when developing Java applications?
Wow, another tough question! I think that the reason that Java has received the reputation of being slow is because of mistakes that the dear programmers have made in ignorance.
I think the most common mistake of Java programmers is that we forget to think! We do not bother to look under the hood of how the ArrayList really works. As a result, we start collecting anecdotes from colleagues of little tricks that supposedly improve Java performance. My tip - never believe anybody when it comes to Java. Check for yourself. That's why Sun publish the source code.
Some of the worst problems I've seen:
1. Strings - A simple thing like adding a String to an Integer can cause quite a few objects to be created. Using Strings incorrectly can cause serious degradation of your application. Don't take my word for it. READ java/lang/String.java, then read java/lang/StringBuffer.java.
2. Dates - especially converting them to Strings.
3. JDBC Drivers can really slow you down. You have to evaluate them in your context. I have found that for some queries, the JDBC/ODBC bridge beat ALL other JDBC drivers for MS SQL Server by a large margin.
4. Arrays - creating new arrays is very expensive. I always try to reuse them where possible. Sun's programmers unfortunately do not.
When I tune code, I prefer working with code that is well factored. Lots of classes, lots of small methods. It makes the tuning much easier.
Q. Which change have you seen applied in a project that gained the largest performance improvement?
The best performance improvements were from changing the design and educating the programmers. In one project, we improved the performance incredibly just by counting the bytes that were going over the sockets and working on reducing network calls.
Once we had optimised the "obvious" things, we also went from Serializable objects to Externalizable, which greatly increased the speed of sending and receiving of objects.
Q. Have you found any Java performance benchmarks useful?
I find them quite amusing, especially the latest one by "The Middleware Company", where they compare .NET and J2EE. My focus is Java, not middleware, but if it was, I would also want to get into the .NET market. Just in case. What better way than to be instrumental in developing the .NET blueprint?
Unfortunately, the lack of the very rare commodity of "thinking" will cause J2EE to become less attractive. If you look at the bigger picture, you must ask yourself - do you really want to be locked in with one vendor? Even if they are faster? According to Rickard Oberg, the report was *seriously* flawed. If that is true, then do you want your future to be 100% on such a company?
Q. Do you know of any performance related tools that you would like to share with our readers?
System.currentTimeMillis();
I try to steer away from commercial tools because I find I work better through using the tricks that I talk about in my newsletter. I have used OptimizeIt with some success in the past, but I found some other popular tools to be too resource-hungry, and they also interfered too much with my code.
The best way that I have personally used is to alter some of the core classes of Java, and put my performance measuring directly into the JDK classes. I then load the classes with the bootclasspath and let my application execute "naturally". You cannot ship your product with modified JDK classes due to license restrictions, but you can do your performance tests like that.
I prefer writing performance code directly into my code. That way I measure only what I am currently focusing on.
Another approach that William Grosso (author of Java RMI) uses is to include the performance code with Aspect/J. I have not done that myself, but I have been told that it is very effective.
Q. Do you have any particular performance tips you would like to tell our readers about?
My #1 tip to anyone doing performance evaluation is this: Make 110% sure that you are measuring the right things!
I have wasted weeks of precious time chasing after performance issues that were no issues. They perhaps showed up in some of the commercial tools, but when I eventually got rid of them, did not make any difference in the overall picture.
Of course, Jack and I cannot tell you the secret of how we know what to measure. We want you think that we know by some dark secret which we are not allowed to divulge by the threat of a horrible death. We'd prefer that when you get to wanting to tune your application, that you give us a call and pay us lots of money [;-)]
(End of interview).
Back to newsletter 024 contents
