File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Performance and the fly likes Java Timing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "Java Timing" Watch "Java Timing" New topic

Java Timing

Inuka Jayasekera

Joined: Dec 21, 2003
Posts: 8
I'm sorry if this is a silly thing to ask but it has been bugging me for a bit and seems to be the only loose end in my project...
I am implementing the Travelling Salesman Problem in java and have created an application that compares 6 of the existing heuristics.
I however, have problems with determining the time that each heuristic takes to run. What I have done for the time being is:
void heuristic() {
before = System.currentTimeMillis();
//TSP Heuristic
after = System.currentTimeMillis();
timeSpent = after - before;
After running the same heuristic with the same input several times, I have found that the value of timeSpent varies by �30 milliseconds which isn't very satisfactory.
I was wandering if anyone might be able to offer a suggestion as to how I could improve the accuracy of the heuristic timing.
Any help would be greatly appreciated...
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
Microbenchmarking can be tricky. Perhaps the most useful thing to do is insure that the test cases run so long that a 30 millisecond change in any of the time becomes insignificant.
The most significant issue when trying to do precise execution time measurements is often garbage collection. Garbage collection is unpredictable and will definately affect the running times. You might want to enable verbose garbage collection (pass -verbose:gc on the command line) to get an idea of how that factors in, although there's a limited amount you can do about it.
steve souza
Ranch Hand

Joined: Jun 26, 2002
Posts: 862
You can run the test many times and take the average. JAMon easily tracks such averages and more. See the links below for more info and a live demo. - a fast, free open source performance tuning api.
JavaRanch Performance FAQ
Tim West
Ranch Hand

Joined: Mar 15, 2004
Posts: 539
Why not increase the problem size until a variation of +/-30msec becomes irrelevant? If you increase the input problem size such that the faster algorithms take around 100 seconds (for ease of calculation :-)), a variation of 30msec is only 0.03%.
This would also help factor out the noise created by programs running in the background and the amount of CPU time allocated to the process. It may also make results more meaningful, in that algorithm performance is most important on 'big' inputs.
Of course, then you get the fun of generating big input problems with known qualities, but that's another game...
I agree. Here's the link:
subject: Java Timing
It's not a secret anymore!