|
|
|
|
Back to newsletter 063 contents
As you may or may not know, I recently took a position at theserverside as a contributing editor. As much fun as it has been - and it has been a lot of fun - it has taken it's toll on this column. Now that I feel more comfortable in my role at TSS, I felt that it is time to revive the monthly roundup of performance discussions across the web.
One of the goals of this roundup is to find interesting questions that have been asked, summarize them and maybe editorialize a bit on the surrounding discussion. The idea was to spark interest or discussions rather then offer a long in-depth position on the subject. However we do appreciate hearing from you in regards to content, style, something that has been stated here that you disagree with, or my favorite, something that you've read here that has helped you meet your performance targets. To give you something fresh to comment on, I offer you this months edition of the performance discussion group roundup.
This month we start with a serverside thread (www.theserverside.com) in which the claim that Thread.sleep() is evil because it doesn't work. The best way to describe this is with the code.
class Main {
public static void main ( String[] args ) {
long start, end, took;
start = System.currentTimeMillis();
for ( int i=0; i<200; i++) {
try {
Thread.sleep (5);
} catch ( Exception ex ) {
ex.printStackTrace();
}
}
end = System.currentTimeMillis();
took = end -start;
System.out.println ("Took: " + took);
}
}
A quick examination of the code and we would expect that this application would print "Took: 1000ms". Ok it should take a wee bit longer then 1000ms because we are also measuring the overhead of the loop. However the comment was that it takes 3500ms to run. The author of the question would appear to be writing a throttle or a trigger to simulate a fixed rate of traffic and so far has been frustrated in this effort. Interestingly enough there would appear to be more going on here then meets the eye. I say this because when I ran the code I got a runtimes that looked like 1175ms. Adjusting the sleep time to 1ms gave me 391ms where as 10ms gave 2141. What this demonstrates is that is that the duration that a thread will "sleep" is almost 100% dependent upon the behavior of the system you are running on. To help us understand why there maybe such a variation we should look at what happens when sleep is called.
When sleep is called, the JVM will make a corresponding system call. That causes the operating system to halt execution of that thread and place it in a non-runnable state. At some point in the future, a clock will issue an interrupt which will cause the thread to become runnable once more. However this does not mean it *will* run, it just says that it is ready *to* run. It is up to the OS to now schedule the thread so that it can re-acquire the CPU. This means that any other thread(s) running on the machine that are completing for the CPU with this thread will interfere with it acquiring that CPU. My Windows XP machine was very quiet when I ran this code and consequently rescheduling most likely happened immediately. The next issue to consider is clock resolution.
In some older machines running older versions of Windows, the clock resolution used in Java was 10ms. What that means is that every time you called sleep, you are going to sleep at least 10ms no matter what. In this case of this loop the minimum sleep time would be 2000ms instead of the expected 1000ms. I actually got tricked on this point while running this test. I had not bothered to test the clock resolution prior to running this test and consequently expected a runtime of at least 2000ms. Just goes to say that one should always "don't guess, measure". There are some more interesting points to be had at http://www.theserverside.com/discussions/thread.tss?thread_id=38490
Since there is so much code coming from India these days we should recognize that they organize numbers slightly different then the rest of us. For example take this post on JavaRanch. "The total number of rows in the data file are around 1 lakh (each line contains 700 characters). We need to dump those data into database." First question that comes to up is what the heck is a lakh? Quick answer is 100,000 which they would write as 1,00,000. If that doesn't twist your eyes try reading this number, 40,00,000. Yes that would be 40lakh or 4 million. The next unit up is the crore. You need 100lakh to get one of these. 40crore would be written like 40,00,00,000.
More to the performance question, this is a case where there were performance problems but it is not clear where they are. But clearly databases are capable of handling this load. Most databases come with bulk loaders that can dispense with this task in a matter of seconds. Why Java was taking 14 minutes is clearly still a mystery though one has to believe that there is something else at the root of this performance problem. Read more at http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=15&t=001186.
If you run the code listed below through the Eclipse compiler with warnings turned, you'll get a warning claiming that the "Read access to enclosing field Extern.extern is emulated by a synthetic accessor method. Increasing its visibility will improve your performance"
class Extern {
private int extern;
private class Intern {
private void doStuff() {
extern = 2;
}
}
}
Question is: what does that warning mean and is there anything to it? And what about design/coding considerations. In other words are the effects so bad that we should ignore good design and coding principles?
In this instance it was the choice of the author to not expose the private instance variable. However Eclipse over-rode that and generated its own get method (hence "synthetic accessor". The problem is, the modifications will be found in your deployed code! So if this is not what you intended to do, it is best to compile with an alternate compiler. On the design side, it is likely better to provide a get method even if that method is marked as private. It really clarifies the point that you want no one to access this variable outside of this immediate class. On the performance front, Hotspot is going to most likely inline the method call thus eliminating any potential performance issues. The thread is http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=15&t=001218
Next month I'll start looking at the performance related features that have been released with Mustang. I look forward to reporting on the progress right here.
Back to newsletter 063 contents