2

In my project I have used java.util.Calendar. They have been working fine for me. They are not deprecated yet. Therefore, I did not feel any need to change java.util.Calendar to java.time.LocalDate in my code. The java.time.LocalDate has many good features. I need to know if java.util.Calendar has some performance issues which is resolved in java.time.LocalDate, so I should change java.util.Calendar in my code to java.time.LocalDate to get higher performance.

Nicolas Filotto
  • 43,537
  • 11
  • 94
  • 122
Nahid Shah
  • 183
  • 2
  • 14
  • It is not a question of performance, but of ease of use. `java.util.Date` is not easy to use, and is flawed in various ways, e.g. 1) It is updatable *(though no one ever really do update them)*, 2) Doesn't have a date-only version, 3) Time zone handling is confusing and error prone, etc. --- You should begin using the new `java.time` classes for their features. It is very unlikely that any performance difference will have an impact on you program. --- *Beware premature optimization:* Fix performance issues when they occur, i.e. when proven to be there, not when you think you might have one. – Andreas Jan 16 '17 at 19:00
  • I don't think you should be worried for performance when you write in java, especially for native/core code – deathangel908 Jan 16 '17 at 19:01
  • Too broad and unclear. Also, there is less information in terms of code for the comparison between the two even based on performance. And nor are the good features stated as suggested in the question.. – Naman Jan 16 '17 at 19:06
  • I asked the question to know about java.util.Calendar and java.time.LocalDate in general. I think Andreas and dethangel908 gave me some good direction. – Nahid Shah Jan 16 '17 at 19:16
  • I think you should consider using the new API. On Android, at least, it can perform up to about 10 times faster. I've tested it myself, and it seems others have too : http://java-performance.info/jsr-310-java-8-datetime-library-performance-well-joda-time-2-3-j-u-calendar/ . No idea why though, and I wish it wasn't immutable, because many times I do wish to change the values, and it should have performed even better in this case, as there is less overhead of creation of instances and GC. – android developer Jan 03 '18 at 08:22
  • I don't know why everyone's getting so off topic, it takes less than a minute to test. From my end, `LocalDate.now()` is clearly superior in performance to `Calendar.getInstance()`, completing 10k iterations in 0-1s (`LocalDate`) vs 2-3s (old) – Krusty the Clown Aug 22 '23 at 20:04

1 Answers1

-1

If you are concerned about performance you should already have performance tests and benchmarks for how your code uses java.util.Calendar. Run those tests and note the time and resource utilization.

Do a conversion of at least some classes to java.time.LocalDate then run the same benchmarks again. Did performance improve or degrade?

There may be some general trends between the two options where one outperforms the other. What really matters though is how your code performs. If it performs better using one or the other then that is what you should use.

Freiheit
  • 8,408
  • 6
  • 59
  • 101