Is System nanoTime completely useless

Question

As documented in the blog post Beware of System nanoTime   in Java  on x86 systems  Java s System nanoTime   returns the time value using a CPU specific counter  Now consider the following case I use to measure time of a call   long time1  System nanoTime    foo    long time2   System nanoTime    long timeSpent   time2-time1    Now in a multi-core system  it could be that after measuring time1  the thread is scheduled to a different processor whose counter is less than that of the previous CPU  Thus we could get a value in time2 which is less than time1  Thus we would get a negative value in timeSpent   Considering this case  isn t it that System nanotime is pretty much useless for now   I know that changing the system time doesn t affect nanotime  That is not the problem I describe above  The problem is that each CPU will keep a different counter since it was turned on  This counter can be lower on the second CPU compared to the first CPU  Since the thread can be scheduled by the OS to the second CPU after getting time1  the value of timeSpent may be incorrect and even negative

User · Answer

No  it s not    It just depends on your CPU  check High Precision Event Timer for how why things are differently treated according to CPU   Basically  read the source of your Java and check what your version does with the function  and if it works against the CPU you will be running it on   IBM even suggests you use it for performance benchmarking  a 2008 post  but updated

User · Answer

Absolutely not useless  Timing aficionados correctly point out the multi-core problem  but in real-word applications it is often radically better than currentTimeMillis      When calculating graphics positions in frame refreshes nanoTime   leads to MUCH smoother motion in my program   And I only test on multi-core machines

User · Answer

This doesn t seem to be a problem on a Core 2 Duo running Windows XP and JRE 1 5 0 06   In a test with three threads I don t see System nanoTime   going backwards  The processors are both busy  and threads go to sleep occasionally to provoke moving threads around    EDIT  I would guess that it only happens on physically separate processors  i e  that the counters are synchronized for multiple cores on the same die

User · Answer

I did a bit of searching and found that if one is being pedantic then yes it might be considered useless   in particular situations   it depends on how time sensitive your requirements are     Check out this quote from the Java Sun site      The real-time clock and   System nanoTime   are both based on   the same system call and thus the same   clock       With Java RTS  all time-based APIs    for example  Timers  Periodic   Threads  Deadline Monitoring  and so   forth  are based on the   high-resolution timer  And  together   with real-time priorities  they can   ensure that the appropriate code will   be executed at the right time for   real-time constraints  In contrast    ordinary Java SE APIs offer just a few   methods capable of handling   high-resolution times  with no   guarantee of execution at a given   time  Using System nanoTime   between   various points in the code to perform   elapsed time measurements should   always be accurate    Java also has a caveat for the nanoTime   method      This method can only be used to   measure elapsed time and is not   related to any other notion of system   or wall-clock time  The value returned   represents nanoseconds since some   fixed but arbitrary time  perhaps in   the future  so values may be   negative   This method provides   nanosecond precision  but not   necessarily nanosecond accuracy  No   guarantees are made about how   frequently values change  Differences   in successive calls that span greater   than approximately 292 3 years  263    nanoseconds  will not accurately   compute elapsed time due to numerical   overflow    It would seem that the only conclusion that can be drawn is that nanoTime   cannot be relied upon as an accurate value  As such  if you do not need to measure times that are mere nano seconds apart then this method is good enough even if the resulting returned value is negative  However  if you re needing higher precision  they appear to recommend that you use JAVA RTS   So to answer your question   no nanoTime   is not useless    its just not the most prudent method to use in every situation

User · Answer

nanoTime is extremely insecure for timing  I tried it out on my basic primality testing algorithms and it gave answers which were literally one second apart for the same input  Don t use that ridiculous method  I need something that is more accurate and precise than get time millis  but not as bad as nanoTime

User · Answer

I have seen a negative elapsed time reported from using System nanoTime    To be clear  the code in question is       long startNanos   System nanoTime         Object returnValue   joinPoint proceed         long elapsedNanos   System nanoTime   - startNanos    and variable  elapsedNanos  had a negative value   I m positive that the intermediate call took less than 293 years as well  which is the overflow point for nanos stored in longs     This occurred using an IBM v1 5 JRE 64bit on IBM P690  multi-core  hardware running AIX  I ve only seen this error occur once  so it seems extremely rare  I do not know the cause - is it a hardware-specific issue  a JVM defect - I don t know  I also don t know the implications for the accuracy of nanoTime   in general   To answer the original question  I don t think nanoTime is useless - it provides sub-millisecond timing  but there is an actual  not just theoretical  risk of it being inaccurate which you need to take into account

User · Answer

I did a bit of searching and found that if one is being pedantic then yes it might be considered useless   in particular situations   it depends on how time sensitive your requirements are     Check out this quote from the Java Sun site      The real-time clock and   System nanoTime   are both based on   the same system call and thus the same   clock       With Java RTS  all time-based APIs    for example  Timers  Periodic   Threads  Deadline Monitoring  and so   forth  are based on the   high-resolution timer  And  together   with real-time priorities  they can   ensure that the appropriate code will   be executed at the right time for   real-time constraints  In contrast    ordinary Java SE APIs offer just a few   methods capable of handling   high-resolution times  with no   guarantee of execution at a given   time  Using System nanoTime   between   various points in the code to perform   elapsed time measurements should   always be accurate    Java also has a caveat for the nanoTime   method      This method can only be used to   measure elapsed time and is not   related to any other notion of system   or wall-clock time  The value returned   represents nanoseconds since some   fixed but arbitrary time  perhaps in   the future  so values may be   negative   This method provides   nanosecond precision  but not   necessarily nanosecond accuracy  No   guarantees are made about how   frequently values change  Differences   in successive calls that span greater   than approximately 292 3 years  263    nanoseconds  will not accurately   compute elapsed time due to numerical   overflow    It would seem that the only conclusion that can be drawn is that nanoTime   cannot be relied upon as an accurate value  As such  if you do not need to measure times that are mere nano seconds apart then this method is good enough even if the resulting returned value is negative  However  if you re needing higher precision  they appear to recommend that you use JAVA RTS   So to answer your question   no nanoTime   is not useless    its just not the most prudent method to use in every situation

User · Answer

Since Java 7  System nanoTime   is guaranteed to be safe by JDK specification  System nanoTime   s Javadoc makes it clear that all observed invocations within a JVM  that is  across all threads  are monotonic      The value returned represents nanoseconds since some fixed but arbitrary origin time  perhaps in the future  so values may be negative   The same origin is used by all invocations of this method in an instance of a Java virtual machine  other virtual machine instances are likely to use a different origin    JVM JDK implementation is responsible for ironing out the inconsistencies that could be observed when underlying OS utilities are called  e  g  those mentioned in Tom Anderson s answer    The majority of other old answers to this question  written in 2009 ndash 2012  express FUD that was probably relevant for Java 5 or Java 6 but is no longer relevant for modern versions of Java   It s worth mentioning  however  that despite JDK guarantees nanoTime   s safety  there have been several bugs in OpenJDK making it to not uphold this guarantee on certain platforms or under certain circumstances  e  g  JDK-8040140  JDK-8184271   There are no open  known  bugs in OpenJDK wrt nanoTime   at the moment  but a discovery of a new such bug or a regression in a newer release of OpenJDK shouldn t shock anybody   With that in mind  code that uses nanoTime   for timed blocking  interval waiting  timeouts  etc  should preferably treat negative time differences  timeouts  as zeros rather than throw exceptions  This practice is also preferable because it is consistent with the behaviour of all timed wait methods in all classes in java util concurrent    for example Semaphore tryAcquire    Lock tryLock    BlockingQueue poll    etc   Nonetheless  nanoTime   should still be preferred for implementing timed blocking  interval waiting  timeouts  etc  to currentTimeMillis   because the latter is a subject to the  time going backward  phenomenon  e  g  due to server time correction   i  e  currentTimeMillis   is not suitable for measuring time intervals at all  See this answer for more information   Instead of using nanoTime   for code execution time measurements directly  specialized benchmarking frameworks and profilers should preferably be used  for example JMH and async-profiler in wall-clock profiling mode

User · Answer

The Java 5 documentation also recommends using this method for the same purpose      This method can only be used to   measure elapsed time and is not   related to any other notion of system   or wall-clock time    Java 5 API Doc

User · Answer

Java is crossplatform  and nanoTime is platform-dependent  If you use Java - when don t use nanoTime  I found real bugs across different jvm implementations with this function

User · Answer

The Java 5 documentation also recommends using this method for the same purpose      This method can only be used to   measure elapsed time and is not   related to any other notion of system   or wall-clock time    Java 5 API Doc

User · Answer

This doesn t seem to be a problem on a Core 2 Duo running Windows XP and JRE 1 5 0 06   In a test with three threads I don t see System nanoTime   going backwards  The processors are both busy  and threads go to sleep occasionally to provoke moving threads around    EDIT  I would guess that it only happens on physically separate processors  i e  that the counters are synchronized for multiple cores on the same die

User · Answer

I did a bit of searching and found that if one is being pedantic then yes it might be considered useless   in particular situations   it depends on how time sensitive your requirements are     Check out this quote from the Java Sun site      The real-time clock and   System nanoTime   are both based on   the same system call and thus the same   clock       With Java RTS  all time-based APIs    for example  Timers  Periodic   Threads  Deadline Monitoring  and so   forth  are based on the   high-resolution timer  And  together   with real-time priorities  they can   ensure that the appropriate code will   be executed at the right time for   real-time constraints  In contrast    ordinary Java SE APIs offer just a few   methods capable of handling   high-resolution times  with no   guarantee of execution at a given   time  Using System nanoTime   between   various points in the code to perform   elapsed time measurements should   always be accurate    Java also has a caveat for the nanoTime   method      This method can only be used to   measure elapsed time and is not   related to any other notion of system   or wall-clock time  The value returned   represents nanoseconds since some   fixed but arbitrary time  perhaps in   the future  so values may be   negative   This method provides   nanosecond precision  but not   necessarily nanosecond accuracy  No   guarantees are made about how   frequently values change  Differences   in successive calls that span greater   than approximately 292 3 years  263    nanoseconds  will not accurately   compute elapsed time due to numerical   overflow    It would seem that the only conclusion that can be drawn is that nanoTime   cannot be relied upon as an accurate value  As such  if you do not need to measure times that are mere nano seconds apart then this method is good enough even if the resulting returned value is negative  However  if you re needing higher precision  they appear to recommend that you use JAVA RTS   So to answer your question   no nanoTime   is not useless    its just not the most prudent method to use in every situation

User · Answer

Since Java 7  System nanoTime   is guaranteed to be safe by JDK specification  System nanoTime   s Javadoc makes it clear that all observed invocations within a JVM  that is  across all threads  are monotonic      The value returned represents nanoseconds since some fixed but arbitrary origin time  perhaps in the future  so values may be negative   The same origin is used by all invocations of this method in an instance of a Java virtual machine  other virtual machine instances are likely to use a different origin    JVM JDK implementation is responsible for ironing out the inconsistencies that could be observed when underlying OS utilities are called  e  g  those mentioned in Tom Anderson s answer    The majority of other old answers to this question  written in 2009 ndash 2012  express FUD that was probably relevant for Java 5 or Java 6 but is no longer relevant for modern versions of Java   It s worth mentioning  however  that despite JDK guarantees nanoTime   s safety  there have been several bugs in OpenJDK making it to not uphold this guarantee on certain platforms or under certain circumstances  e  g  JDK-8040140  JDK-8184271   There are no open  known  bugs in OpenJDK wrt nanoTime   at the moment  but a discovery of a new such bug or a regression in a newer release of OpenJDK shouldn t shock anybody   With that in mind  code that uses nanoTime   for timed blocking  interval waiting  timeouts  etc  should preferably treat negative time differences  timeouts  as zeros rather than throw exceptions  This practice is also preferable because it is consistent with the behaviour of all timed wait methods in all classes in java util concurrent    for example Semaphore tryAcquire    Lock tryLock    BlockingQueue poll    etc   Nonetheless  nanoTime   should still be preferred for implementing timed blocking  interval waiting  timeouts  etc  to currentTimeMillis   because the latter is a subject to the  time going backward  phenomenon  e  g  due to server time correction   i  e  currentTimeMillis   is not suitable for measuring time intervals at all  See this answer for more information   Instead of using nanoTime   for code execution time measurements directly  specialized benchmarking frameworks and profilers should preferably be used  for example JMH and async-profiler in wall-clock profiling mode

User · Answer

This answer was written in 2011 from the point of view of what the Sun JDK of the time running on operating systems of the time actually did  That was a long time ago  leventov s answer offers a more up-to-date perspective   That post is wrong  and nanoTime is safe  There s a comment on the post which links to a blog post by David Holmes  a realtime and concurrency guy at Sun  It says      System nanoTime   is implemented using the QueryPerformanceCounter QueryPerformanceFrequency API       The default mechanism used by QPC is determined by the Hardware Abstraction layer HAL        This default changes not only across hardware but also across OS versions  For example Windows XP Service Pack 2 changed things to use the power management timer  PMTimer  rather than the processor timestamp-counter  TSC  due to problems with the TSC not being synchronized on different processors in SMP systems  and due the fact its frequency can vary  and hence its relationship to elapsed time  based on power-management settings    So  on Windows  this was a problem up until WinXP SP2  but it isn t now   I can t find a part II  or more  that talks about other platforms  but that article does include a remark that Linux has encountered and solved the same problem in the same way  with a link to the FAQ for clock gettime CLOCK REALTIME   which says         Is clock gettime CLOCK REALTIME  consistent across all processors cores   Does arch matter   e g  ppc  arm  x86  amd64  sparc           It should or it s considered buggy       However  on x86 x86 64  it is possible to see unsynced or variable freq TSCs cause time inconsistencies  2 4 kernels really had no protection against this  and early 2 6 kernels didn t do too well here either  As of 2 6 18 and up the logic for detecting this is better and we ll usually fall back to a safe clocksource       ppc always has a synced timebase  so that shouldn t be an issue    So  if Holmes s link can be read as implying that nanoTime calls clock gettime CLOCK REALTIME   then it s safe-ish as of kernel 2 6 18 on x86  and always on PowerPC  because IBM and Motorola  unlike Intel  actually know how to design microprocessors    There s no mention of SPARC or Solaris  sadly  And of course  we have no idea what IBM JVMs do  But Sun JVMs on modern Windows and Linux get this right   EDIT  This answer is based on the sources it cites  But i still worry that it might actually be completely wrong  Some more up-to-date information would be really valuable  I just came across to a link to a four year newer article about Linux s clocks which could be useful

User · Answer

This answer was written in 2011 from the point of view of what the Sun JDK of the time running on operating systems of the time actually did  That was a long time ago  leventov s answer offers a more up-to-date perspective   That post is wrong  and nanoTime is safe  There s a comment on the post which links to a blog post by David Holmes  a realtime and concurrency guy at Sun  It says      System nanoTime   is implemented using the QueryPerformanceCounter QueryPerformanceFrequency API       The default mechanism used by QPC is determined by the Hardware Abstraction layer HAL        This default changes not only across hardware but also across OS versions  For example Windows XP Service Pack 2 changed things to use the power management timer  PMTimer  rather than the processor timestamp-counter  TSC  due to problems with the TSC not being synchronized on different processors in SMP systems  and due the fact its frequency can vary  and hence its relationship to elapsed time  based on power-management settings    So  on Windows  this was a problem up until WinXP SP2  but it isn t now   I can t find a part II  or more  that talks about other platforms  but that article does include a remark that Linux has encountered and solved the same problem in the same way  with a link to the FAQ for clock gettime CLOCK REALTIME   which says         Is clock gettime CLOCK REALTIME  consistent across all processors cores   Does arch matter   e g  ppc  arm  x86  amd64  sparc           It should or it s considered buggy       However  on x86 x86 64  it is possible to see unsynced or variable freq TSCs cause time inconsistencies  2 4 kernels really had no protection against this  and early 2 6 kernels didn t do too well here either  As of 2 6 18 and up the logic for detecting this is better and we ll usually fall back to a safe clocksource       ppc always has a synced timebase  so that shouldn t be an issue    So  if Holmes s link can be read as implying that nanoTime calls clock gettime CLOCK REALTIME   then it s safe-ish as of kernel 2 6 18 on x86  and always on PowerPC  because IBM and Motorola  unlike Intel  actually know how to design microprocessors    There s no mention of SPARC or Solaris  sadly  And of course  we have no idea what IBM JVMs do  But Sun JVMs on modern Windows and Linux get this right   EDIT  This answer is based on the sources it cites  But i still worry that it might actually be completely wrong  Some more up-to-date information would be really valuable  I just came across to a link to a four year newer article about Linux s clocks which could be useful

User · Answer

No  it s not    It just depends on your CPU  check High Precision Event Timer for how why things are differently treated according to CPU   Basically  read the source of your Java and check what your version does with the function  and if it works against the CPU you will be running it on   IBM even suggests you use it for performance benchmarking  a 2008 post  but updated

User · Answer

This doesn t seem to be a problem on a Core 2 Duo running Windows XP and JRE 1 5 0 06   In a test with three threads I don t see System nanoTime   going backwards  The processors are both busy  and threads go to sleep occasionally to provoke moving threads around    EDIT  I would guess that it only happens on physically separate processors  i e  that the counters are synchronized for multiple cores on the same die

User · Answer

No  it s not    It just depends on your CPU  check High Precision Event Timer for how why things are differently treated according to CPU   Basically  read the source of your Java and check what your version does with the function  and if it works against the CPU you will be running it on   IBM even suggests you use it for performance benchmarking  a 2008 post  but updated

User · Answer

I have seen a negative elapsed time reported from using System nanoTime    To be clear  the code in question is       long startNanos   System nanoTime         Object returnValue   joinPoint proceed         long elapsedNanos   System nanoTime   - startNanos    and variable  elapsedNanos  had a negative value   I m positive that the intermediate call took less than 293 years as well  which is the overflow point for nanos stored in longs     This occurred using an IBM v1 5 JRE 64bit on IBM P690  multi-core  hardware running AIX  I ve only seen this error occur once  so it seems extremely rare  I do not know the cause - is it a hardware-specific issue  a JVM defect - I don t know  I also don t know the implications for the accuracy of nanoTime   in general   To answer the original question  I don t think nanoTime is useless - it provides sub-millisecond timing  but there is an actual  not just theoretical  risk of it being inaccurate which you need to take into account

User · Answer

The Java 5 documentation also recommends using this method for the same purpose      This method can only be used to   measure elapsed time and is not   related to any other notion of system   or wall-clock time    Java 5 API Doc

User · Answer

No need to debate  just use the source  Here  SE 6 for Linux  make your own conclusions   jlong os  javaTimeMillis       timeval time    int status   gettimeofday  amp time  NULL     assert status    -1   linux error      return jlong time tv sec    1000     jlong time tv usec   1000       jlong os  javaTimeNanos       if  Linux  supports monotonic clock          struct timespec tp      int status   Linux  clock gettime CLOCK MONOTONIC   amp tp       assert status    0   gettime error        jlong result   jlong tp tv sec     1000   1000   1000    jlong tp tv nsec       return result      else       timeval time      int status   gettimeofday  amp time  NULL       assert status    -1   linux error        jlong usecs   jlong time tv sec     1000   1000    jlong time tv usec       return 1000   usecs

User · Answer

Also  System currentTimeMillies   changes when you change your systems clock  while System nanoTime   doesn t  so the latter is safer to measure durations

User · Answer

Java is crossplatform  and nanoTime is platform-dependent  If you use Java - when don t use nanoTime  I found real bugs across different jvm implementations with this function

User · Answer

No need to debate  just use the source  Here  SE 6 for Linux  make your own conclusions   jlong os  javaTimeMillis       timeval time    int status   gettimeofday  amp time  NULL     assert status    -1   linux error      return jlong time tv sec    1000     jlong time tv usec   1000       jlong os  javaTimeNanos       if  Linux  supports monotonic clock          struct timespec tp      int status   Linux  clock gettime CLOCK MONOTONIC   amp tp       assert status    0   gettime error        jlong result   jlong tp tv sec     1000   1000   1000    jlong tp tv nsec       return result      else       timeval time      int status   gettimeofday  amp time  NULL       assert status    -1   linux error        jlong usecs   jlong time tv sec     1000   1000    jlong time tv usec       return 1000   usecs

User · Answer

This doesn t seem to be a problem on a Core 2 Duo running Windows XP and JRE 1 5 0 06   In a test with three threads I don t see System nanoTime   going backwards  The processors are both busy  and threads go to sleep occasionally to provoke moving threads around    EDIT  I would guess that it only happens on physically separate processors  i e  that the counters are synchronized for multiple cores on the same die

User · Answer

Absolutely not useless  Timing aficionados correctly point out the multi-core problem  but in real-word applications it is often radically better than currentTimeMillis      When calculating graphics positions in frame refreshes nanoTime   leads to MUCH smoother motion in my program   And I only test on multi-core machines

User · Answer

Linux corrects for discrepancies between CPUs  but Windows does not  I suggest you assume System nanoTime   is only accurate to around 1 micro-second  A simple way to get a longer timing is to call foo   1000 or more times and divide the time by 1000

User · Answer

I am linking to what essentially is the same discussion where Peter Lawrey is providing a good answer  Why I get a negative elapsed time using System nanoTime     Many people mentioned that in Java System nanoTime   could return negative time  I for apologize for repeating what other people already said    nanoTime   is not a clock but CPU cycle counter  Return value is divided by frequency to look like time  CPU frequency may fluctuate  When your thread is scheduled on another CPU  there is a chance of getting nanoTime   which results in a negative difference  That s logical  Counters across CPUs are not synchronized  In many cases  you could get quite misleading results but you wouldn t be able to tell because delta is not negative  Think about it   unconfirmed  I think you may get a negative result even on the same CPU if instructions are reordered  To prevent that  you d have to invoke a memory barrier serializing your instructions    It d be cool if System nanoTime   returned coreID where it executed

User · Answer

I am linking to what essentially is the same discussion where Peter Lawrey is providing a good answer  Why I get a negative elapsed time using System nanoTime     Many people mentioned that in Java System nanoTime   could return negative time  I for apologize for repeating what other people already said    nanoTime   is not a clock but CPU cycle counter  Return value is divided by frequency to look like time  CPU frequency may fluctuate  When your thread is scheduled on another CPU  there is a chance of getting nanoTime   which results in a negative difference  That s logical  Counters across CPUs are not synchronized  In many cases  you could get quite misleading results but you wouldn t be able to tell because delta is not negative  Think about it   unconfirmed  I think you may get a negative result even on the same CPU if instructions are reordered  To prevent that  you d have to invoke a memory barrier serializing your instructions    It d be cool if System nanoTime   returned coreID where it executed

User · Answer

nanoTime is extremely insecure for timing  I tried it out on my basic primality testing algorithms and it gave answers which were literally one second apart for the same input  Don t use that ridiculous method  I need something that is more accurate and precise than get time millis  but not as bad as nanoTime

User · Answer

The Java 5 documentation also recommends using this method for the same purpose      This method can only be used to   measure elapsed time and is not   related to any other notion of system   or wall-clock time    Java 5 API Doc

User · Answer

Also  System currentTimeMillies   changes when you change your systems clock  while System nanoTime   doesn t  so the latter is safer to measure durations

User · Answer

I did a bit of searching and found that if one is being pedantic then yes it might be considered useless   in particular situations   it depends on how time sensitive your requirements are     Check out this quote from the Java Sun site      The real-time clock and   System nanoTime   are both based on   the same system call and thus the same   clock       With Java RTS  all time-based APIs    for example  Timers  Periodic   Threads  Deadline Monitoring  and so   forth  are based on the   high-resolution timer  And  together   with real-time priorities  they can   ensure that the appropriate code will   be executed at the right time for   real-time constraints  In contrast    ordinary Java SE APIs offer just a few   methods capable of handling   high-resolution times  with no   guarantee of execution at a given   time  Using System nanoTime   between   various points in the code to perform   elapsed time measurements should   always be accurate    Java also has a caveat for the nanoTime   method      This method can only be used to   measure elapsed time and is not   related to any other notion of system   or wall-clock time  The value returned   represents nanoseconds since some   fixed but arbitrary time  perhaps in   the future  so values may be   negative   This method provides   nanosecond precision  but not   necessarily nanosecond accuracy  No   guarantees are made about how   frequently values change  Differences   in successive calls that span greater   than approximately 292 3 years  263    nanoseconds  will not accurately   compute elapsed time due to numerical   overflow    It would seem that the only conclusion that can be drawn is that nanoTime   cannot be relied upon as an accurate value  As such  if you do not need to measure times that are mere nano seconds apart then this method is good enough even if the resulting returned value is negative  However  if you re needing higher precision  they appear to recommend that you use JAVA RTS   So to answer your question   no nanoTime   is not useless    its just not the most prudent method to use in every situation

User · Answer

Linux corrects for discrepancies between CPUs  but Windows does not  I suggest you assume System nanoTime   is only accurate to around 1 micro-second  A simple way to get a longer timing is to call foo   1000 or more times and divide the time by 1000

User · Answer

No  it s not    It just depends on your CPU  check High Precision Event Timer for how why things are differently treated according to CPU   Basically  read the source of your Java and check what your version does with the function  and if it works against the CPU you will be running it on   IBM even suggests you use it for performance benchmarking  a 2008 post  but updated

[java] Is System.nanoTime() completely useless?

Examples related to java

Examples related to nanotime