Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java Timing

 
Inuka Jayasekera
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
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
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 862
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim West
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic