Funny nanotimer performance

We're slowly closing in with version 2 of the Java Simon and during the process I tried to test how we stand against JAMon after adding things like Callbacks. Truth is that Simon now does a bit more than before and I was curious about the impact. I compiled JamonComparison class from our examples, started it and... shock! Man, it can't be THAT bad. Simon was incredibly slower than the JAMon. I didn't believe it was only because of more processing in the Simon because in our previous tests in both cases (Simon/JAMon) timer calls were the slowest part by far. That led me to our other micro-test that measures how precise are milli- and nano-timers. And in case of nanotime also how fast it can return the results. I compiled SystemTimersPrecision and when I ran it I discovered that nanotimer needs nearly 2000 ns for every call. This was in contrast with my previous measurement when it needed around 250 ns.

I'm not sure if it's JDK update or Windows XP update - the thing is that you generally don't choose your JDK/OS combination to have fast nanotimer calls, do you? :-) Check our Wiki page on this topic to find more results in the article and comments bellow it. It's unlucky that the call costs so much on various Windows systems but it still shouldn't be show-stopper when you need to measure something. If you need to track some fast methods, millis are unusable anyway, nanos are fine, but the overhead is bigger (even 10 times), but at least you have your results. If you measure something long-running than the overhead is not so significant. Long-running is anything with I/O involved, DB access for instance (something our JDBC proxy driver can help you with). Sure, you could use other product with millis in that case, but I'm pretty sure Java Simon can convince you with the architecture, extensibility via Callbacks, JMX support and also that often mentioned JDBC proxy driver. Of course, if you need something else entirely, go for it.

Java Simon v2 is over-due, we know it, but I still want to write about Callbacks and Configuration before we release it. But whatever is now in the trunk, it's pretty close to the final version.