Trying to measure elapsed time in Java

I was unable to get the Java clock to measure the time elapsed in milliseconds from the beginning to the end of a simple program.

I've copied the program below. You will see that I used the utility Calendar, then printed the time before and after the loop. No matter how long the loop takes, the time shown by the print command before and after the loop does not change.

Can you suggest a solution?

I use DrJava.

import java.util.Calendar;

class time
  public static void main(String[] args)

    int sum=0;
    int i=0;
    int j=0;
    int n=300;

    Calendar cal = Calendar.getInstance();

    System.out.println("Current milliseconds since 13 Oct, 2008 are :" + cal.getTimeInMillis());

    for (i=0;i < n; i++)
      System.out.println("ROW " + i);  

    System.out.println(" Current milliseconds since 13 Oct, 2008 are :" + cal.getTimeInMillis());




To measure elapsed time.

This is available since Java 1.5, monotonic (where possible, method details).

If you want precise measurements of elapsed time, use System.nanoTime().

From the Java Documentation:

public static long nanoTime()

Returns the current value of the most precise available system timer, in nanoseconds.

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 years (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.

For example, to measure how long some code takes to execute:

long startTime = System.nanoTime();
// ... the code being measured ...
long estimatedTime = System.nanoTime() - startTime;

From the docs:

Calendar's getInstance method returns a Calendar object whose calendar fields have been initialized with the current date and time:

You have to get a new instance after the loop, and get that instance's time in milliseconds.

Also, 300 iterations of a simple loop isn't likely to register any time at all, even if measured in milliseconds. You might want to try 300 thousand (300000) iterations or more.

Also note that even if getTimeInMillis() returns a particular number of milliseconds, be aware that it's probably not updated that frequently. It might only be updated every 10 milliseconds or so (when the system tick happens). This depends entirely on your operating system implementation.

long start = System.currentTimeMillis();

/*** do stuff***/

double elapsed = (System.currentTimeMillis() - start) / 1000.0;

A bit of clarity about why your choice doesn't work out the way expect.

Calendar represents a moment in time, with various locale-dependent operations on it, and not something like a running clockwork.

As Greg suggested, you should do a larger number of iterations. His argument is valid - that and statistically speaking, having a larger sample will yield more accurate results (this will eliminate random deviations due to uncontrollable events like gc, enviroment, etc.).

Need Your Help

NSubstitute and Covariance Support?

c# task-parallel-library covariance nsubstitute

I'm trying to test some TPL dataflow code and run into what looks like a covariance issue with NSubstitue param matching. It is asserting:

Generic component for XML using SAX parser

java android xml parsing sax

I am an Android developer, I have to create a generic component for parsing xml using sax parser. For any kind of schema I should create a common component through which we can parse the xml and save

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.