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.

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"

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.