CODEWITHSUNDEEP
javaalgorithmruntimejvm-hotspot
Klaus
Klaus

Reputation:

Java task runtime

First of all I have to admit that these are very basic and primitive questions... I want to demonstrate different Algorithms in Java for sorting and searching, and to get a value for the runtime. There're issues I cannot solve:

  1. there's Hotspot compiling - which is a runtime optimization I need to deactivate (I guess).

  2. How do I get time-values (seconds) for runtimes? Starting a timer before the execution and stopping it afterwards... seems a little primitive. And the timer-object itself consumes runtime... I need to avoid that.

Is there anything in the Java API one could utilize to solve these problems?

Thanks, Klaus

Upvotes: 2

Views: 497

Answers (3)

Peter Lawrey
Peter Lawrey

Reputation: 533670

Using System.nanoTime() twice consumes less than 1 micro-second. I suggest you run any benchmark for a number of second and take an average so a micro-second error won't be significant.

Overall, I would suggest not making things more complicated than you need it to be.

To have a built in warm up I often ignore the first 10%-20% of iterations. Something like

long start;
int count;
for(int i = -count / 5; i < count; i++) {
    if (count == 0) start = System.nanoTime();
    // do tested code
}
long time = System.nanoTime() - start;
long average = time / count;
System.out.printf("Average time was %,d micro-seconds%n", average / 1000);

Upvotes: 1

Yuval Adam
Yuval Adam

Reputation: 165282

  1. Use -Xint JVM flag. Other options can be seen here.

  2. Use the ThreadMXBean API to get CPU/User times for your thread. An example can be seen here.

Upvotes: 1

Tom Hawtin - tackline
Tom Hawtin - tackline

Reputation: 147164

You can disable HotSpot with -Xint on the command line, to get an order of magnitude decrease in performance. However, why don't you want to measure real world performance? Different things can become bottlenecks when you compile.

Generally for microbenchmarks:

  • use System.nanoTime to get a time measurement at the start and end
  • run for a reasonable length of time
  • do the measurement a number of times over (there's some "warm up")
  • don't interleave measurements of different algorithms
  • don't do any I/O in the measured segment
  • use the result (HotSpot can completely optimise away trivial operations)
  • do it in a real world situation (or a cloae as possible)
  • remember dual core is the norm, and more cores will become normal

Upvotes: 5

Related Questions