• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java Timing

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 862
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic