• Post Reply Bookmark Topic Watch Topic
  • New Topic

Date vs System.currentTimeMillis

 
Allen Bandela
Ranch Hand
Posts: 128
Eclipse IDE MS IE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there a general consensus on which of the two is faster?
new Date().getTime() or System.currentTimeMillis()
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The constructor for Date() uses System.currentTimeMillis(), so the latter must be faster: -


That said, the difference will be so microscopic that no-one should care.

The above shows there is no point using Date purely to get the current time in the form of a long. But if your application would use the other features of a Date, use one.
 
Campbell Ritchie
Marshal
Posts: 52587
119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Last month's Java Developers' Newsletter contains this link. Read it and use ctrl-F to find "performance." Now you see Goetz tells us not to worry about performance at all, but to leave it all to the compiler.

There are a few instances where we can improve performance, eg by using a fast algorithm for sorting a large array rather than Bubble Sort, but in the main it is a waste of time trying to write "fast" code.

If you want to see how long each call takes, have a look at this recent thread where different processes ran at different speeds on Windows and on Linux (on the same PC). Also note the use of System.nanoTime() to find out how long a method takes. Try the same with your invocations, and see whether there is a significant difference.

[edit]Corrected spelling error in URL[/edit]
[ April 13, 2007: Message edited by: Campbell Ritchie ]
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Campbell Ritchie:
Last month's Java Developers' Newsletter contains this link.Now you see Goetz tells us not to worry about performance at all, but to leave it all to the compiler.


Hopefully, by this you mean don't worry about micro-optimisations. I would agree with that. But, unless writing really trivial stuff, it is still good to think about the architecture and algorithms being used.

Micro-optimisations rarely save even a few percent of run-time, and are often defeated by the cleverness of HotSpot. But architectural and algorithmic choices can affect the speed by factors of hundreds or thousands and the compiler can't work-around poor architectural choices.
 
Campbell Ritchie
Marshal
Posts: 52587
119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Micro-optimisation?
I presume that is what Goetz means. I have a 1000000-member array which I created "for entertainment purposes" and I have a "bubble" (more precisely sinking) sort algorithm to sort it, which take about 1 hr 40 min. I also have a recursive merge sort for the same array with runs in about 0.4 seconds. There was discussion about performance two weeks ago here, where I suggested you can use the System.nanoTime() method to time a method call. I have tried it and System.current . . . is a lot quicker. Presumably there is a lot of time wasted setting up the Date object with fields one doesn't use.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Micro-optimization means optimizing features at the micro level - e.g. a small fragment of code - without looking and measuring how it behaves in the larger (macro) context. Performance can vary substantially depending on environment and on how (and how often) other classes are calling your method. Brian Goetz is not saying don't worry about performance at all. He's saying don't worry about performance at first - instead focus on clean, simple code. Then measure the performance at the macro level - how fast is the code when you run the whole program at once, preferably in an environment like where it will run in production. If you find a performance problem there, then you do some profiling to identify where it is. It may be in some small coding detail like whether you used new Date().getTime() or System.currentTimeMillis(). But very often, it's not. Often in complex systems it's not even in code you wrote, but in some external library. Trying to optimize without proper overall (macro) measurements is usually a waste of time.

As for Campbell's experience with new Date().getTime(), I would guess that the method being time was very short and was called many, many times in the execution of the program. That's the main circumstance under which micro-optimization is useful. The Date class doesn't have much in the way of fields - only two, and one of those is usually left null. But still, it's an object, and it takes more resources than a single primitive variable does. Garbage collection nowadays is significantly faster than it was in the early days of Java - but primitives are still usually faster than objects. In a very short method called many times, this can be significant.

Anyway, ignoring all that - yeah, in those cases where the difference is noticeable, System.currentTimemillis() will most always be faster than new Date().getTime(). If there's no particular reason to create a Date, don't make one.
 
steve souza
Ranch Hand
Posts: 862
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The brian goetz article is good. I placed a link to it as well as some of the main points in the enterprise performance faq's link that appears at the bottom of the email.

His articles are consistently good. Here is a link to them from his homepage: http://www.briangoetz.com/pubs.html

Here are some of the more important quotes from the interview:
* "If I could wave a magic wand and send out one message about Java programming, it would be this: Trust the JVM. It's smarter than you think. Stop trying to outwit or outsmart it. Tell it what you want, and it will do its damnedest to make your application run as fast as it can."
* "Developers love to optimize code and with good reason. It is so satisfying and fun. But knowing when to optimize is far more important. Unfortunately, developers generally have horrible intuition about where the performance problems in an application will actually be."
* "The answer may seem counterintuitive. Often, the way to write fast code in Java applications is to write dumb code -- code that is straightforward, clean, and follows the most obvious object-oriented principles."
* "Most performance problems these days are consequences of architecture, not coding -- making too many database calls or serializing everything to XML back and forth a million times."
* "This perception, that synchronization is really expensive, is another performance myth, one that was true 10 years ago but is no longer true. Every major JDK release has reduced the overhead of synchronization over the previous version. Yes, there's still overhead, but people worry too much about that and not enough about writing clean, correct code."
* "Because C programmers are trained to focus on bit-level microperformance issues, they tend to bring this obsession with them to Java programming and miss the forest for the trees."
* "Java software has always had the potential to be faster than C. The performance improvements in Java SE 6 make it clear that we're heading toward that goal. We're just beginning to apply the optimizations coming out of the Java compiler research community to production languages."
* "In memory management, Java technology is already significantly faster than C, and yet people incorrectly believe that it's expensive and that developers should preallocate and pool their objects."
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!