Replace currentTimeMillis() with nanoTime() for duration measuring

[Vampire]

No description provided.

[hcoles]

What is the issue this is addressing?

[Vampire]

The issues this is adressing is, that you should not use System.currentTimeMillis() for measuring durations within one JVM, but System.nanoTime() if the duration is less than 292 years. It is more precise and not influenced by things like wall clock, system time, and similar that influence System.currentTimeMillis().

[hcoles]

Nano time costs more cpu cycles, although that is unlikely to have a measurable impact. Only concret benefit seems to be that there are (or were) issues with currentTimeMillis on windows, where the accuracy was ~50ms by default, which would indeed be an issue if it's still the case. We need time within about 1ms.

[Vampire]

nanoTime is faster than currentTimeMillis on some systems (afair mainly Linux), but slower on others.
But the main point is, that currentTimeMillis is not monotonic. It depends on wall-clock. If you change your system time while PIT is running, you get wrong results, this could also be done by some time synchronization utility for example.
nanoTime on the other hand is monotonic and especially there to measure durations within one JVM.
It should practically always be used when measuring durations within one JVM instance.