回答:
System.currentTimeMillis()
オブジェクトを作成しないため、明らかに最も効率的new Date()
ですが、実際には長いラッパーであり、それほど遅れていません。Calendar
一方、日付と時刻に固有のかなりの複雑さとすべての奇妙さ(うるう年、夏時間、タイムゾーンなど)に対処する必要があるため、は比較的遅く、非常に複雑です。
一般に、Date
アプリケーション内の長いタイムスタンプまたはオブジェクトのみを処理し、Calendar
実際に日付/時刻の計算を実行する必要がある場合、またはユーザーに表示するために日付をフォーマットする場合にのみ使用することをお勧めします。これをたくさん行う必要がある場合は、インターフェースをよりクリーンにしてパフォーマンスを向上させるために、Joda Timeを使用することをお勧めします。
JDKを見ると、の最も内側のコンストラクタにCalendar.getInstance()
は次のものが含まれています。
public GregorianCalendar(TimeZone zone, Locale aLocale) {
super(zone, aLocale);
gdate = (BaseCalendar.Date) gcal.newCalendarDate(zone);
setTimeInMillis(System.currentTimeMillis());
}
そのため、あなたが提案したことはすでに自動的に行われています。日付のデフォルトのコンストラクタはこれを保持します:
public Date() {
this(System.currentTimeMillis());
}
したがって、カレンダー/日付オブジェクトを作成する前にそれを使って計算したい場合を除いて、特にシステム時間を取得する必要はありません。また、日付計算を頻繁に処理することが目的である場合は、Java独自のカレンダー/日付クラスの代わりとして使用するjoda-timeを推奨する必要があります。
日付を使用する場合は、http: //joda-time.sourceforge.net/のjodatimeを使用することを強くお勧めします。使い方System.currentTimeMillis()
のフィールドにしているあなたは役に立たない多くのコードになってしまいますので、非常に悪いアイデアのように日付音。
日付とカレンダーはどちらも深刻な問題を抱えており、カレンダーは間違いなくそれらすべての中で最悪のパフォーマーです。
System.currentTimeMillis()
あなたが実際にミリ秒で操作しているときに使用することをお勧めします、例えばこのような
long start = System.currentTimeMillis();
.... do something ...
long elapsed = System.currentTimeMillis() -start;
アプリケーションによっては、System.nanoTime()
代わりに使用を検討したい場合があります。
nanoTime
戻る時間は(通常はプログラムの開始に対して)相対的であり、日付に変換しようとしても意味がありません。
私はこれを試しました:
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);
そして結果は:
日付():199
currentTimeMillis():3
System.currentTimeMillis()
メソッド呼び出しが1つだけであり、ガベージコレクターが必要ないため、明らかに最速です。