System.nanoTime() very slow on linux

Performance Tuning
#1

System.nanoTime() is a great way to find performance problems when System.currentTimeMillis’s resolution isn’t sufficient.

But I had to discover the drawback of System.nanoTime when I compared the runtime of a benchmark on windows and linux.
To my surprise it turned out that windows took something like 1.23 msec and linux took 1.67 msec for the same algorithm (computing the silhouette of a 3d object) on the same jdk version(1.5.0_06). It turned out that actually the operating system doesn’t influence the duration of the algorithm, but that System.nanoTime() is so much slower on linux than on windows!

Is this a known effect (Maybe this is a notebook specific effect due to CPU power saving)? I think it’s particularly bad that the longer duration of System.nanoTime influences the measurement itself!

As a workaround: What high precision, low impact timer that runs on both windows and linux can you recommend (that also works on notebooks - where simple RTDSC based timers appear to fail)?

Yours,
Stefan

#2

Im not doubting the authenticity of what you say; but when your going to run the actual algorithm, your not going to be keeping those nanoTime calls there are you? Its like running your game with a profiler enabled, not much sense :slight_smile:

Btw, how did you find out how long nanoTime took? By using nanoTime with a for loop? :stuck_out_tongue:

DP

#3

On linux, System.currentTimeMillis() has 1millisecond precision. Only on windows is it very bad (as far as I know), with 55ms accuracy.

If that small difference in speed of System.nanoTIme() is a pain for you but 1ms accuracy is OK, use System.currentTimeMillis() on linux & System.nanoTIme() on windows.

#4

I actually consider removing the profiling functions once it’s done :wink:

Currently I’m profiling the time per object and there are about 130 objects in the scene and thus 260 calls to System.nanoTime.

#5

This means that any differences in time taken by nanoTime is actually below noise level if you remove that abundance of calls to it, right?