Système.currentTimeMillis() vs. new Date () vs. Calendar.getInstance().getTime()
En Java, ce sont les performances et les conséquences sur les ressources de l'aide
System.currentTimeMillis()
vs.
new Date()
vs.
Calendar.getInstance().getTime()
si je comprends bien, Système.currentTimeMillis() est le plus efficace. Cependant, dans la plupart des applications, cette longue valeur devrait être convertie en une Date ou un objet similaire pour faire quelque chose de significatif pour les humains.
8 réponses
System.currentTimeMillis() est évidemment le plus efficace car il ne crée même pas un objet, mais new Date() est vraiment juste un emballage mince sur une longue, il n'est donc pas loin derrière. Calendar , d'autre part, est relativement lent et très complexe, car il doit faire face à la complexité considérable et toutes les bizarreries qui sont inhérentes aux dates et aux heures (années bissextiles, l'heure d'été, les fuseaux horaires, etc.).
c'est généralement un bon idée de ne traiter que les objets Date ou Date dans votre application, et n'utiliser Calendar que lorsque vous avez réellement besoin d'effectuer des calculs date/heure, ou de formater des dates pour les afficher à l'utilisateur. Si vous devez faire beaucoup de cela, utiliser Joda Time est probablement une bonne idée, pour l'interface plus propre et de meilleures performances.
en regardant le JDK, le constructeur le plus proche de Calendar.getInstance() a ceci:
public GregorianCalendar(TimeZone zone, Locale aLocale) {
super(zone, aLocale);
gdate = (BaseCalendar.Date) gcal.newCalendarDate(zone);
setTimeInMillis(System.currentTimeMillis());
}
donc il fait déjà automatiquement ce que vous suggérez. Le constructeur par défaut de Date tient ceci:
public Date() {
this(System.currentTimeMillis());
}
donc il n'y a vraiment pas besoin d'obtenir l'heure du système spécifiquement à moins que vous vouliez faire quelques calculs avec elle avant de créer votre calendrier/Date objet avec elle. Aussi, je dois recommander joda-time à utiliser comme remplacement pour Les propres classes de date/calendrier de Java si votre but est de travailler avec des calculs de date beaucoup.
si vous utilisez une date alors je vous conseille fortement d'utiliser jodatime, http://joda-time.sourceforge.net / . Utiliser System.currentTimeMillis() pour les champs qui sont des dates semble être une très mauvaise idée parce que vous finirez avec beaucoup de code inutile.
la date et le calendrier sont sérieusement borked, et le calendrier est certainement le pire d'entre eux tous.
je vous conseille d'utiliser System.currentTimeMillis() lorsque vous sont en fait fonctionnant avec des millisecondes, par exemple comme ceci
long start = System.currentTimeMillis();
.... do something ...
long elapsed = System.currentTimeMillis() -start;
, je préfère utiliser la valeur retournée par System.currentTimeMillis() pour toutes sortes de calculs et d'utiliser uniquement Calendar ou Date si je dois vraiment afficher une valeur qui est lu par les hommes. Cela empêchera également 99% de vos bogues d'heure avancée. :)
sur ma machine j'ai essayé de le vérifier. Mon résultat:
Calendar.getInstance().getTime() (*1000000 times) = 402ms new Date().getTime(); (*1000000 times) = 18ms System.currentTimeMillis() (*1000000 times) = 16ms
N'oubliez pas GC (si vous utilisez Calendar.getInstance() ou new Date() )
selon votre application, vous pouvez envisager d'utiliser System.nanoTime() à la place.
j'ai essayé ceci:
long now = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
new Date().getTime();
}
long result = System.currentTimeMillis() - now;
System.out.println("Date(): " + result);
now = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
System.currentTimeMillis();
}
result = System.currentTimeMillis() - now;
System.out.println("currentTimeMillis(): " + result);
et le résultat était:
Date(): 199
currentTimeMillis (): 3
System.currentTimeMillis() est évidemment le plus rapide parce qu'il s'agit d'une seule méthode et qu'aucun collecteur d'ordures n'est nécessaire.