How can I measure time with microsecond precision in Java?

前端 未结 12 856
死守一世寂寞
死守一世寂寞 2020-12-03 01:15

I saw on the Internet that I was supposed to use System.nanoTime() but that doesn\'t work for me - it gives me the time with milliseconds precision. I just need

相关标签:
12条回答
  • 2020-12-03 02:00

    If you want a reliable result, use a profiler. I suggest VisualVM, which is easy to install and is bundled with the JDK starting from version 1.6.0_07.

    It is an easy to use visual tool that integrates several commandline JDK tools and lightweight profiling capabilities.

    0 讨论(0)
  • 2020-12-03 02:01

    System.nanoTime() uses a counter in the CPU and is usually accurate to about 1 micro-second on Windows XP and Linux.

    Note: Windows XP is often less accurate on multi-cpu machines as it doesn't compensate for different CPUs having different counters. Linux does. Note 2: It will drift relative to the System.currentTimeMillis() as it is based on the accuracy of the clock for your CPU (which doesn't need to be so accurate over a period of time), rather than the clock you have for getting the time.(which drifts less per day, but has less granularity)

    In your benchmark you are basically testing the speed at which you can create new objects. Not surprisingly your results will vary dramatically based on your GC settings and how recently a GC has been performed.

    Try running your tests with the following options and you should see very different results.

    -verbosegc -XX:NewSize=128m -mx256m
    
    0 讨论(0)
  • 2020-12-03 02:02

    Such a benchmark that relies on short time-interval gives you unreliable results. You will always get different results, because of external factors like I/O, Swapping, Process Switches, Caches, Garbage Collection etc. Additionally the JVM optimizes your calls, so it's likely that the first measured things are going slower than later call. The JVM starts more and more to optimize the commands you execute.

    Additionally the method like System.nanoTime() is dependent on the timers of the underlying system. They may (and most likely will) not have the granularity to measure in that accuracy. To cite the API:

    This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change.

    To really measure with high precision you need to access an external timing hardware with guaranteed precision.

    To make your benchmark more stable you need to execute it more than once and to measure bigger time-intervals than only milliseconds.

    0 讨论(0)
  • 2020-12-03 02:10

    It may be the case that the underlying OS doesn't provide timers with nanosecond precision.

    There is also an older post.

    0 讨论(0)
  • 2020-12-03 02:12

    It's not clear to me exactly what you're benchmarking, but in general, any test which takes such a short amount of time to run, that accuracy lower than 50 ms is relevant, is going to be very prone to other disturbances.

    I generally try to make benchmarks run for at least 10 seconds. The framework I'm writing at the moment will guess how many iterations to run so that it will take 30 seconds. That means you won't get radically different results just because some other process stole the CPU for a few milliseconds.

    Running for longer is almost always a better approach than trying to measure with finer-grained accuracy.

    0 讨论(0)
  • 2020-12-03 02:13

    For our recent profiling, I found that ThreadMXBean.getCurrentThreadCpuTime() and the option -XX:+UseLinuxPosixThreadCPUClocks did what we needed.

    See http://bugs.java.com/view_bug.do?bug_id=6888526 for more details

    0 讨论(0)
提交回复
热议问题